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ABSTRACT 


Complex  design  problems  are  characterized  by  a  multitude  of 
competing  requirements.  The  designer  of  such  a  system 
frequently  finds  the  scope  of  the  problem  beyond  his  concep¬ 
tual  abilities  and  attempts  to  solve  this  problem  by 
decomposing  the  design  problem  into  smaller  more  manageable 
subproblems.  Since  design  requirements  form  the  interface 
between  the  users  of  a  system  and  its  designers,  a 
disciplined  framework  is  required  for  the  decomposition  of 
the  design  problem  into  subproblems  which  will  best  satisfy 
the  overall  problem  objective. 

Cluster  analysis  is  a  heuristically  based  technique  by  which 
attributes  of  a  system  are  sorted  into  groups;  such  that, 
the  degree  of  "natural"  association  is  high  among  members  of 
the  same  group  and  low  between  members  of  different  groups. 

"The  purpose  of  this  thesis  is  to  investigate  the  use  of  a 
specific  cluster  analysis  technique,  developed  by  Dr.  Raphael 
Andreu.  As  a  means  of  imposing  a  framework  upon  the 
requirements  for  an  existing  computer  operating  system 
forming  the  first  step  in  the  decomposition  of  the  global 
design  problem  into  subproblems.  It  is  envisioned  that  the 
imposition  of  such  a  framework  on  design  requirements  will 
provide  new  insights  and  understanding  of  the  relationships 
among  requirements  which  may  verify  the  design  or  suggest 
improvements  to  the  design  of  a  sample  operating  system.^ 

Stuart  Madnick 
Professor  of  Management 
Thesis  Supervisor 
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ABSTRACT 

Complex  design  problems  are  characterized  by  a  multitude  of 
competing  requirements.  The  designer  of  such  a  system 
frequently  finds  the  scope  of  the  problem  beyond  his  concep¬ 
tual  abilities  and  attempts  to  solve  this  problem  by 
decomposing  the  design  problem  into  smaller  more  manageable 
subproblems.  Since  design  requirements  form  the  interface 
between  the  users  of  a  system  and  its  designers,  a 
disciplined  framework  is  required  for  the  decomposition  of 
the  design  problem  into  subproblems  which  will  best  satisfy 
the  overall  problem  objective. 

Cluster  analysis* is  a  heuristically  based  technique  by  which 
attributes-  of  a  system'  are  sorted  into  groups?  such  that, 
the  degree  of  "natural"  association  is  high  among  members  of 
the  same  group  and  low  between  members  of  different  groups. 

The  purpose  of  this  thesis  is  to  investigate  the  use  of  a 
specific  cluster  analysis  technique,  developed  by  Dr.  Raphael 
Andreu.  As  a  means  of  imposing  a  framework  upon  the 
requirements  for  an  existing  computer  operating  system 
forming  the  first  step  in  the  decomposition  of  the  global 
design  problem  into  subproblems.  It  is  envisioned  that  the 
imposition  of  such  a  framework  on  design  requirements  will 
provide  new  insights  and  understanding  of  the  relationships 
among  requirements  which  may  verify  the  design  or  suggest 
improvements  to  the  design  of  a  sample  operating  system. 
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CHAPTER-  I 

DESCRIPTION  OF  THE'  PROBLEMS  INHERENT 
IN  LARGE  SCALE  SYSTEM  DESIGN 


1.1.  Problem.  Description 

The  design  of  complex  systems  is  characterized  by  many 
of  the  following  problems  as  identified  by  Andreu  and 
Madnick .* 

.  There,  is  no  established  framework  in  which  the  design: 
decisions  can  be  coordinated  among  various  design 
groups.  This  can  lead  to  an  optimization  of  sub¬ 
problems,  but  sub-optimization  of  the  aggregate  design 
^problem. 

.  The  adaptiveness  of'  the  system  to  changes  in  opera¬ 
tional  requirements  is  made  difficult  and  time 
consuming  since  such  changes  often  impact  the  entire 
system. 

.  The  incorporation  of  new  technology  into  an  existing 
system  is  cumbersome  and  expensive  since  there  is  no 
systematic  me.\ns  of  assessing  the  impact  of  new 
technology  oh  the  system  operation. 

.  System  performance  evaluation  may  require  an  enormous 
model  to  represent  the  entire  system. 

I 

1 

Raphael  Anareu  and  Stuart  Madnick ,  "A  Systematic  Approach  to 
the  Design  of  Complex  Systems:  Application  to  DBMS  Design  and 
Evaluation" 3  Center  for  Information  Systems  Research 3  Report 
Z2}  Sloan  School  of  Management 3  MIT  (Cambridge ,  MA,  1977)  p.6. 


•  .  The  designer  has  ho  means  to  determine  if  the 

.problem  has  been  completely  and  consistently  defined, 

or  alternatively;/  over-pons  trained. 

The  most  common  technique  currently  in  use  to  simplify  the 

design  of  a  complex  system  is  to  decompose  the.  global  problem 

into  smaller  stab-problems .  However,  without  proper  guidance, 

this  leads  to  many  of  the  following  problems  as  documented 

2 

by  Mandel  and  Chryssostomidis . 

.  The  Subdivision,  of  a  given  problem  into  lower  level 
problems  imposes  limitations  on  accuracy  and  is, 
therefore,  an  approximation.  This  implies  that  the 
optimization  of  the  subproblems  does  not  necessarily 
lead  to  total  system  optimization. 

A  designer  of ‘a  specific  sub-problem  is  likely  to 
have  incomplete  knowledge  of  the  total  problem. 

.  The  decomposition  process  should  be  independent  of 

any  specific  technology  or  implementation  technique. 

The  designer  of  a  large  scale  system  is  faced  with  a  number 

of  possible  pitfalls  as  the  size  and  complexity  of  the 

design  problem  increases.  The  problems  can  be  loosely 

defined  a3  a  lack  of  a  consistent  framework  in  which  to  make 

3 

design  decisions,  Fred  Brooks  has  defined  this  problem  as 

2  . 

P.  Mandel  and'  C.  Chryssostomidis ,  "A  Design  Methodology  For 
Ships  and  Other  Complex  Systems ",  Phil.  Trans.  R.  Soo.,  London 
A. 273,  ( London ,  1972),  p.87. 

3 

Fred  Brooks,  The  Mythical  Man-Month:  Essays  on  Software 


one  of  conceptual  integrity,  and  identified,  this'  as  the.  most 
important  consideration'  in  system  design.  Conceptual 
integrity  in  this  context  dictates  rigorous  design  sequence , 
for.  if  there  is  no  rigor  in  -the  design,  the  resulting 
product  of.  the  design  process  is  highly  idiosyncratic;,  in  the 
worst  case,  it  is  based  on  the  failure  history  of  the  parti¬ 
cipants  .  As  a.  final  measure,  rigorous  design  should  survive 
its  implementation  and  provide  a  framework  for  intellectual 
control  of  changes  to  design  requirements  change. 


1 .2  System  Development  Cycle 

In  order  to  develop  a-  rigorous  and  consistent  framework 
for  the  design  process,  one  must  examine  structure  of  the 
design  problem  as  it,  exists  in  general  in  order  to  propose 
improvements  to  the  structure.  Although  many  procedures  have 
be*?,n  defined  for  a  typical  computer  software  design  problem, 
Andreu  favored  the  following-  System  Development  Cycle  as 
proposed-  by  Freeman  to  illustrate  the  nature  of  the  design 
problem.. 

Figure  1  is  a  representation  of  the  five  steps  which 
Freeman  recognized  in  the  design  cycle.  Each  step  consists 
of  an  input  and  output  and  an  operation  which  take  place 
ih  each  step.  The  function  of  each  step  is  now  further 
defined  from  the  perspective  of  the  need  to  establish  a 
framework  in  which  the  global  design  problem  may  be 
decompoised. 


NEEDS  ANALYSIS- 

Input:  Primitive  needs,  system  context,  user  problems. 
Operation:  Identification  of  major  functions  and  constraints. 
Output:1  General  requirements. 


(2)  FUNCTIONAL  SPECIFICATION 

Input:  Requirements,  system  analysis  of  context, 

•Operation:  Conversion  of  needs  into  explicit  functions,  selection 
of  operational  constraints. 

Output:  Specifications  of  system  functions,  constraints,  and 
objectives. 


(3)  ARCHITECTURAL  DESIGN- .  . 

Input:  Specifications,  general  context  of  desired  systems, 
knowledge  of  similar  problems. 

Operation:  Discovery  of  problem  structure,  identification  of  major 
pieces  of  system,  establishment  of  relationships 
between  parts i  abstraction. 

Output:  Structural  description  of  system. 


(4)  DETAILED  DESIGN  SPECIFICATION 

Input:  Architectural  description,  programming  environment' 
details. 

Operation:  Abstraction,  elaboration,  choice  of  alternatives. 
Output:  Blueprints  for  programs. 


(5)  IMPLEMENTATION 

Input:  Blueprints. 

Operation:  Encoding  of  algorithms  and  data  representations, 
testing,  debugging. 

_  Output:;,  Improved  system. 


FIGURE  1.1:  The  System  Development  Cycle 

■4 Raphael  Andreu,  "A  Systematic  Approach  to  the  Design  and'  Structuring 
of  < Complex  Software  System",  unpublished  Doctoral  thesis,  MIT  Sloan 
School  of  Management,  February,  1978. 


1.2.1  NEEDS;  ANALYSIS:' 

This  stage  of  the  design  process,  incorporates  a  careful 
assessment  -of:  the  needs  which  the  final  system- must  fulfill.. 
This  stage  is  generally  the  mos -  unstructured  of  all  the 
stages;;  since,  a  new  system  must  be.  designed  to;  respond  to 
the  user’s  percieved  needs.  The  information  derived  from 
the.  stage  ranges  from  the  most  nebulous  of  statements  of 
need ,  to  statements  of  such  detail  as  to  actually  specify 
implementation .  The  lack  of  structure  in  this  phase  of  the 
design  process  is  likely  to  introduce-  errors  which  will  be 
repreated  throughout  the  remaining  stages  of  the  design 
process . 

In  order,  to  avoid  the  errors  introduced  by  a  poor  needs 
analysis  phase  and  driven  by  a  desire  to  apply  the  decom¬ 
position  methodology  to  an  untested  system  design,  an 
existing  well-documented  computer  operating  system  was 
selected  for  analysis. 

1. 2.2  FUNCTIONAL  SPECIFICATION; 

ThiSvStage  of  the  design  process  is  concerned  with  the 
development  of  documentation  aids  in  order  to  generate 
formal  and  accurate  statements  of  the  system  requirements. 
Typically,  functional  specifications  are  characterized  by 
many  of  the  following  properties:  completeness,  consistency, 
correctness,  testability,  non-ambiguity,  design  freedom, 
and  robustness  to  change.  Obviously,  the  generation  of 
functional  specifications  is  not  an  easy  task,  usually  taking 


place,  as  an  iterative  or  refining  process  in  which  the 
global  system  requirements  are  continually  refined  until  the 
system  is  completely  defined. 

Numerous  research  efforts  are  currently  underway  to 

formalize  the  process  of  functional  specifications.  One. 

.particular  method  developed  by  TRW,  Defense  and  Space  Systems 

Group  is  called  the  Software  Requirements  Engineering 

5 

Methodology  (SREM)..  It  is  an  automated  system  which 
attempts  to  enforce  -the  discipline  of  a  framework  in  the 
individual  interpretation,  of  the  problem  by  the  design 
engineer  to  reduce  the;  ambiguity  of  software  requirements 
and  thereby  lead'  to  increased  consistency  in  functional 
specifications . 

In  addition ,  other  "problem  statement  languages" 
developed  by  Tiechroew  and:  others^  have  identified  two 
classes  of  requirements;  specifically,  " functional"  require¬ 
ments  i  what  the  system  is  to  do  and  ''performance"  require¬ 
ments,  regarding  constraints  on  measures  of  system  behavior. 

No  attempts  were  made  in  this  thesis  to  implement  any 
of  the  problem  statement  languages,  as  such.  However,  a 
series  of  guidelines  for  requirements  definition  were 
established  to  insure  that  the  requirements  had  all  the 
characteristics  of  a  "well-defined"  set  of  requirements.  The 

^  Carl  G.  Davis  and  Charles  R.  Vick ,  *'The  Software'  Development 
System",  IEEE  TRANSACTIONS  ON  SOFTWARE  ENGINEERING,  Vdl.  SE-3 
No.  1  ( Jan  1977),  p.70. 

6 

Sloan  School,  MIT,  " System  Documentation,  Language  Report", - 
unpublished  Sloan  School  report,  MIT,  Sloan  School  .(.Cambridge 
MA) ,  p. 2 . 
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classification  of  functional  versus  performance  requirements:, 
developed  in.  the  problem  statement  languages were  used  in 
the  interdependency  assessment,  process,. 

1> 2. 3  ARCHITECTURAL  DESIGN : 

This  stage  of  the  design  process  is  concerned'  with  the. 
discovery  of  problem  structure  in  the  design  as  defined  by 
Freeman.  That  is,  the  identification  of  major  sub-problems 
of  the  system  and  the  establishment  of  relationships  between 
these  sub-problems.  Utilizing,  this  technique,  AndreU  has 
noted  the  existence  of  both  a  problem  structure  and  a  system 
structure  inherent  in  each  system  design. 

The  problem  structure  is  concerned  with  how  different 
parts  of  the  system  interact  from  a  design  standpoint;  that 
is,  what  parts  of  the  system  can  be  designed  independently 
of  others  as  opposed  to  what  parts  must  be  designed  at  the 
same  time.  The  problem  structure  then  is  used  to  identify 
the  trade-offs  that  must  be  taken  into  account  between 
completing  solutions  of  the  design  problem.  The  concept  of 
a  problem  structure  was  a  key  element  used  in  the  inter¬ 
dependency  assessment  phase. 

The  system  structure,  on  the  other  hand;  is  concerned 
with  how  system  parts  interact  once  the  system  is  designed 
and  in  operation *  Andreu  has  pointed  out  that  the  two 
structures  do  hot-  necessarily  coincide: 

"Traditionally  the  'design  problem  structure' 
has  been,  determined  by  the  system  structure  in 


that  it  is  very  common  to  organize  the  design 
of  a  new  system  around  *  standard '  system 
structures,  drawn  from  similar,  systems,  pre¬ 
viously  designed. 1,7 

As  previously  stated,  a  subdivision  of  a  given  problem  into 
lower  level  problems  imposes  limitations  on  accuracy  and  is, 
therefore,  an  approximation.  Secondly,  unless  the  process 
is  rigorous;,  it  is  highly  idiosyncratic.  The  goal  of  any 
proposed  framework  must  be  to  reduce  the  designer's  depend¬ 
ency  on  "standard"  system  structures  in  such  a  way  as  to 
rigorously  decompose  the  design  problem:  into  well-defined 
subproblems . 

Therefore,  a  framework:  is*  required  at  this  stage  of;  the 
design  process,  to  resolve  the  traderoffs  that  may  exist 
among  system  requirements  as  implied  by  available  alternative 
implementation,  techniques.  Andreau  has  proposed  a  framework 
which  addresses  this  issue  based  on  cluster  analysis  tech¬ 
niques.  The  purpose  of  the  framework  is  to: 

,  explicitly  establish  the  nature  of  the  problem  by 
decomposition; 

.  establish  a  consistent  framework  in  which  trade-offs 
can  be  assessed. 

The  methodology  constitutes  a  well-structured  series  of 

activities  that  the  software  engineer  should  perform  during 

the  design  process.  The  value  of  such  a  methodology,  claims 

* 

Andre  u, 

2  Andreu,  p.\41. 
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"i .  .is  that  the  concept  of  interrelated  design 
subproblems-  stemming  from  the.  explicit  inter¬ 
dependencies  among  requirements ,  constitutes  a-. 

.better  basis  for  the  subsequent'  detailed  design- 
stages  than  the,  original  disjointed  set  of 
requirements.”8 

1.2.4  DETAILED  DESIGN  SPECIFICATION.: 

This  stage  constitutes  the  actual  design  of  program 

9 

modules  as  opposed  to  system  design.  The  work  of  Parnas 
has  focused  on  the.  means,  of  structuring  the  software  modules 
in  order  to  implement  the  system.  This  stage  is  beyond  the 
concern  of  this  thesis ; 

1.2.5  IMPLEMENTATION : 

This  stage  is  concerned  with  the  actual  programming  of 
the  system.  Efforts  by  Listov*0  have  attempted  to  develop 
structural  programming  tools  to  systematize  the  activities 
at  this  stage  of  the  design.  This  stage  is  also  beyond  the 
concern  of  this  thesis. 


1.3  Summary 

The  system  development  cycle  is  characterised:  by 


Andreu,  p.4f. 

9 

David  L .  Parnas,  "On  the  Criteria  to  be  Used  in  Decomposing 
System  into  Modules ",  Communications  of  the  ACM.,  Vol .  15, 
Humber  i2  ( Dec .  19.72),  pp,  1053-1058 . 

^ Barbara  Liskov  and  Valdis  Berzins,  "An  Appraisal  of  Program 
Specifications ",  Computation  Structures  Group  Memo  141-1,  MIT. 
Laboratory  for  Computer  Science  (April  1977),  p.1-12. 
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increasing,  attempts  to  structure  or  systematize  each;  .stage 
of  the>  design  process  .  The  purpose,  of  this  thesis,  is  to 
apply  the  techniques  developed  by  Andreu-  in  order  to  verify 
the  design  of  the  computer  operating  'system  under  investi¬ 
gation  by  the  application  of  the  methodology  as  proposed  by 
Andreu . 

1.4-  Thesis  Outline 

The  computer  operating  system  entitled,  "The  Sample 
Operating  System  (SOS) "  was  developed  by  Professor  Madnick 
and  Professor  Donovan13-  of  the  MIT  Sloan  School  of  Manage¬ 
ment.  This  system  design  problem  was  selected  for  examina¬ 
tion  since  it  is  a  reasonably  non-trivial  and  well-documented 
software  design  problem. 

Chapter  II  is  devoted  to  a  discussion  of  cluster 
analysis  techniques  in  general,  and  a  description  of  the 
specific  methodology  proposed  by  Andreu; 

Chapter  III  presents  a  description  of  the  general 
characteristics  of  the  sample  operating  system. 

Chapter  IV  presents  both  the  procedure  and  the  results 
of  the  requirements  definition  phase  for  the  sample  operating 
system.  .  This  chapter  presents  in  detail  the  guidelines  which 
were  used  to  generate  the  requirements  and,  by  example, 
demonstrate  some  of  the  pitfalls-  encountered  in  requirements 
definition. 

13 Stuart  E.  Madniok  and  John  J.  Donovan Operating  Svstems, 
(Hew  larky  1974 )>  pp. 331-431. 


Chapter.  V  .presents  the  methodology  for  the  interdepend¬ 
ency  assessment  phase  and'  the  resulting  input  for.  analysis 
utilizing  Andreu's-  methodology . 

Chapter  VI  presents  the  results  of  the  first  decomposi¬ 
tion  using  the.  analytic  techniques  .previously  described; 

These  results  are  considered  an  intermediate  step;  therefore, 
the  results  are  analyzed  as  motivation  to  continue  along  in 
the  next  set  decomposition. 

Chapter  VII  presents  the  results  of  the  second  decom¬ 
position  analysis  and  compares  the  results  with  those 
previously  obtained. 

Chapter  VIII  presents  a  comparison  of  the  design  frame¬ 
work  implied  by  the  decomposition  methodology  vis-a-vis  the 
actual  design  of  the  sample  operating  system. 

The  final  chapter  will  present  suggestions  for  changes 
or  improvements  to  the  cluster  analysis  techniques  proposed 
by  Andreu,  based  on  the  experience  of  the  user. 


CHAPTER  II 

CLUSTER  ANALYSIS  METHODOLOGY-  AND 
THE  DECOMPOSITION  FACILITY 

s. 

This  'Chapter  is  devided  into  three  sections  in-  order  to 
present  the  cluster  analysis  methodology  as  applied  to  the 
general  decomposition  problem. 

First,  the  need  for  such  a  methodology  is  motivated  by 
establishing  the  objective  pf  such  cluster  analysis  tech¬ 
niques  and  the  types  of  problems  encountered  in  the  applica¬ 
tion.  of  the  methodology.  Definitions  of  general  terms  are 
offered  for  use  through  the  rest  of  the  discussion. 

Second,  a  solution  to  the  decomposition  problem  using; 
cluster  analysis  techniques  is  defined.  Specifically,  the 
decomposition  problem  is  defined-  and  the:  techniques  for 
partitioning  the  requirements  set  are  presented  according  to 
the  work  by  Andrei i 

Finally,  the  use  of  the  decomposition  software  analysis 
techniques  developed  by  Andreu  are  presented. 

2.1  Cluster  Analysis  Problem 

Cluster  analysis  techniques  may  be  defined  as  analysis 
techniques  to  sort  the  attributes  of  objects  into  groups 
such  that  the  degree  of  natural  association  is  high  among 
members  of  the  same  group  and  low  between  members  of  dif¬ 
ferent  groups.  When  successfully  applied,  the  techniques 
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•can  be  used  to  reveal  -problem,  structure  as  relationships 
that  .existfor  a  given  set  of  data. 

In  order  to  apply  these  techniques-,  one  must  be  capable 
of  the  following: 

.  Definition  of  a  group  of  objects  to  be  clustered;  in 
this  case,  design  requirements  for  a  computer 
operating  system. 

i  Selection  and  common  definition  of  attributes  common 
to  all  objects  In  .this  group;  in  this  case-,  the 
singular  attribute  selected  was  the  existence  of  an 
interrelationship  between  ai  ;given  pair  of  requirements . 
The  definition  of  interrelationship  will  be  discussed 
in  Chapter  V. 

..  Definition  of  ah  evaluation  parameter  so  that  the 
degree  of:  natural  association  among  members  of 
clusters  may  be  measured. 

.  Definition  of  an  algorithm  to  find  the  best  partition 
of.  a  group  of  Objects.  Specifically,  an  algorithm  . 
which  defines  a  partition  with  the  "best"  measure 
evaluation  parameter  without  having  to  evaluate  all 
the  possible,  partitions. 

The  following  definitions  have  been  applied  to  the 
cluster  analysis  problem. 

In  general,  a  group  of  objects  0,  may  be  defined  as 
follows; 

Let  0  :  {0^, . .  .0^.-.  .Ojj}  be  the  set  of  objects  in 


which-  the  clusters  are  to  be  identified.  These 
are'  -composed  of  individual  design  requirements 
and.  also  represent  the  nodes  of  any  graphs  which 
are  drawn,  j N |  may  be  defined  as  the  cardinality 
of  a  set  of  objects;  that  is,  the  number  of 
objects  within  a  given,  set. 

Each  object  may  be  characterized  by  a  set  of  attributes : 

(  X  :  '{X^.  *.,X. ...  X^}  -measured  in  some  consistent  scale. 

In  the  case  of  the  discussion,  the  attribute  is  the 

f 

existence  of  interdependencies . 

Therefore ,  introducing  a  slight  change  of  notation,  an  object 
0^ »e  0  is  characterized  by  a  vector. 

A  :{  (a^ ,  aij  *  1  if.  nodes  0^  and  Oj  are  related*  an 
interdependency • exists ;  *  0  otherwise.  This  is  the  so-called 
adjacency  matrix  in  which  it  is  assumed  that  aij.  «  1  when 
i  *  j. 

The  adjacency  matrix  is  constructed  by  making  a  pair¬ 
wise  assessment  of  the  relationships  among  all  pairs  of 
requirements.  The  adjacency  matrix  is  simply  an  NXN  matrix, 
where  N  is  the.  number  of  requirements  objects ;  Once  a  set 
of  objects  and  their  interrelationships  have  been  established 
the  next  problem  is  defining  evaluation  parameters  to  measure 
the -degree  of  natural  association. 

2.1.2  EVALUATING  SET  DECOMPOSITIONS: 

Any  method  for  evaluating  the  success  of  a  decomposition 
scheme  must  consider  the  strength  of  intra-subset  relation- 


ships,,  .and:  some  means  for  combining,  these  two;  parameters.! 

Therefore,’  the  following  evaluation  parameters  were  defined 
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by  Andreu.  ■ 

Strength:-  A  measure,  of  how  tightly  coupled  the  modes 
in  a  given:  subgraph  are  is  defined  as  follows: 


Number  of  links,  joining  nodes 
in  the  same  subset 


-  (N  -  1) 


N  (N-l):|  2 

where  a  subgraph  is  a  graph  composed  of  a  subset  of  the 
original  members  of  the  total  graph  of  nodes  to  be  decomposed . 
Strength  is  evaluated  by  measuring  the  number  of  links 
joining  nodes  in  the  same  subset  minus  N-i,  N  being  tbe 
cardinality  of  the  given  subset,  normalized  by  a  factor  of 

N(N-l)/2.  In  a  subset  of  N  nodes,  N-l  is  the  minimum  number 

• 

of  interdependencies  which  can  form  as  subgraphs  without 
disjointed  components;  thus,  the  number  of  links  in  excess 
of  N-l  is  a  measure  of  subset  internal  coherence,  beyond  the 
minimum  required  for  it  to  be  coherent  at  all .  The  factor 
N(N-l)/2  is  the  maximum  number  of  links  that  may  exist  in  a 
subset  of  cardinality  N;  normalizing  by  the  factor  permits 
comparable  measures  for  subsets,  of  different  cardinality. 

Coupling:  a  measure-  of  the  extent  to  which  two  sub¬ 
sets  are  independent,  and  is  defined  as  follows: 

f  Number  of  links  actually  joining  ) 


nodes  of  two  different  subsets  j 


Andreu 


In  order  to  evaluate  the  coupling  parameter  ,  the-  number  of 
interdependencies  established  between  two.  nodes  in-  different,  t 
subsets-  are  counted  and  normalized  by  the  factor  N'M;  where 
N  and  M  are  the  cardinalities  of  -the  two  subsets . 

Measure;  The  final  evaluation  parameter  of  clustering 
success  for  a  given  partition  may  be  defined  as  follows; 

P  -P 

M  -IS,  -  I  Cij 
1*1  1  i-1 

j'*i+l 

The  measure  parameter  represents  the.  summation  of  all  the 
strengths  of  all  subsets  in  the  given  partition  minus  the 
couplings  associated  with  all  possible  pairs  of  subsets. 

P  is  defined  as.  a  partition  Or  subgraph  of  the  original 
requirements  set.  Appendix  A  contains  a  formal  definition 
Of  each  of  the  evaluation  parameters  listed  above. 

The  parameters  are  defined  so  that  the  measure  value 
should  be  large  to  indicate  a  good  evaluation  of  the  natural 
association  of  a  partition  generated  by  cluster  analysis 
techniques.  Therefore,  given  a  group  of  partitions  one 
would  select  the  partition  with  the  highest  value  of  measure 
as  representing  the  "best”  partition. 

Given  a  requirements  set,  attributes  in  the  form  of 
interdependencies  and  evaluation  parameters  as  previously 
defined;  one  is  now  faced  with  the  problem  of  determining  an 
algorithm  which  will  generate  the  best  partition  for  a 
requirements  set  of  non-trivial  size. 


2,1.3  CLUSTERING  SCHEMES': 

Given  an  adjacency  matrix  and  evaluation  parameter  as 

previously  defined,,  a  technique,  is  now  needed  to  deal  with  a 

non-trivial  decomposition  .problem-  which  would'  not  require 

having  tc>  investigate  or  compute'  all  feasible  decompositions 

that  exist  for  a  given  requirements  set.  A  heuristically 
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based  procedure  was,  selected  by  Andreu  since  he  has 
demonstrated . that  neither  an  optimization  nor  a  graph 
theoretic  approach  is  feasible  to  solve  a  problem  of  non¬ 
trivial  size.  Therefore,  the  various  families  of  cluster 
analysis  techniques  and  heuristic  graph  decomposition  tech-, 
niques  were  investigated  to  determine  which  were  the  raOst 
feasible . 

in  general ,  there  are  two  generic  types  of  cluster 
analysis  methods ,  the  heirarchical  method  and  the  partition¬ 
ing  method.  The  following  discussion  will  focus  upon  the 
similarities  and  differences  of  the  two  methods,  concluding 
with  the  rationale  for  the  method  selected  for  use  by 
Andreu . 

However*  prior  to  a  discussion  of  actual  cluster  analy¬ 
sis  methods,  the  following  definition  of  the  concept  of  a 
distance  matrix  must  be  presented  to  transition  from  the 

adjacency  matrix  of  interdependence  established  between 

--  >' 

design  requirements  to  a  similarity  matrix;  defined  cluster 
analysis  techniques;  The  binary  assessment  procedure,  used 
for  identifying  requirement  with  dependences  is  simplistic 
^ AndveUj  pp .203-109 . 


'but  It  is  not  useful  for  defining  distances  as  established 
for  Euclidan  geometry.  For  the  purposes  of  cluster  analysis 
.techniques;  specifically,,  computing  similarity  matrix  S, 
scale  conversions  may  be  needed'  prior,  to  the  representation 
of  a  pair  of  objects  X^  and  Xj  Into  an  entry  of  the  form 
Sij.  ■  (X^,Xj )  in  the  similarity  matrix.  The  scale  conver¬ 
sions  must  meet  the  properties  of  "metrics’*  which  is  one  type: 
of  distance  function. 

The  formal  properties  of  metrics  have  been  identified 
by  Anderberg  as  follows: 

"Let  S  be  a  symbolic  representation  for  a  measurement 

space  and  let  x,  y,  and  z  be  any  three  points  in  S. 

Then  a  distance  function  D  is  a  metric  if  and  only  if 

It  satisfies  the  following  conditions: 

1.  D(x,y)  ■  0  if  and  only  if  x*y 

2.  D(x,y)  >  0  for  all  x  and  y  in  S 

3.  D(x,y)  *  D(y,x)  for  all  x  and  y  in  S 

H 14 

4.  D (x,y)  <■  D (Xjz)+D (y, z)  for  all  x,  y,  and  z  in  S 

The  first  property  implies  that  x  is  zero  distance  from 
itself  and  that  any  two  points  zero  distance  apart  must  be 
identical.  The  second  property  prohibits  negative  distances. 
The  third  property  implies  symmetry  by  requiring  the  distance 
from  x  to  y  to  be  the  same  as  the  distance  from  y  to  x.  The 
fourth  property,  the  triangle  inequality,  requires  that  the 
length  of  one  side  of  the  triangle  be  no  longer  then  the  sum 
of  the  lengths  of  the  other  two  sides.  The  satisfaction  of 

Michael  R.  Andevbevg ,  Cluatev  Analysis  fov  AvvHoations a 
(New  York,  1973),  p. 99. 
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these- properties  is  required  so  that;  the  concept,  of  distance; 
is  the  Euclidean  distance  of  elementary  geometry .  Once  the 
•property  is  established  the  well-known  properties,  of 
Euclidean  distance  geometry  can  be  applied,  to  similarity 
matrices. 

A  distance  function  which  satisfies  the;  first  three: 
conditions  of  a  metric,  but  not  the-  triangle  inequality  is: 
known1  as  a  semimetric .  Furthermore ,  a  metric  -which 
additionally  satisfies  the:  following  property 

D(x,y)»MAX{D  (x,z)  ,D(y,z) }  for  all  x,  yv  z  in  S 
is  called  an  ultrametric  since  the  latter  property  is  con¬ 
siderably  stronger  than  the  triangle  inequality. 

15  • 

Andreu  has  pointed  out  that  the  concept  of  cluster 
analysis  is  not  a  precise  technique  since  it  is  heuristically 
based.  Furthermore,  Blashfield  and  Aldenderfer^  have  shown 
that  the  various  cluster  analysis,  methods  do,  in  fact, 
generate  different  solutions- to  the  same  data;  Therefore, 
the  value  of  the  methodology  is  strictly  dependent  upon: 

1)  The-  number  of  subsets  into  which  the  original  set 

is  decomposed,  where  the  maximum  *  N  and  the 
minimum  *  I.  Q 

2)  The  extent  to  which  the  clusters  are  individually 
coherent  and  Collectively  are  distinctly  different.. 

^  A'ndreu,  v.,223. 

is 

Roger  K.  Blashfield  and  Mark  S.  Aldenderfer,  " A  Consumer 
Report  on  Cluster  Analysis  Software" ,  Pennsylvania  State 
University  Report  CPA,  29?3}t  p.3. 
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The  two  approaches-  to  cluster'  analysis  techniques , 
'discussed:  in-  the  following,  section,  differ  in  the,  means  by 
which  they  approach  a  middle-ground  Solution  to  either 
extreme. 

2.1. 3.1  Agglomerative  Techniques:* 

The  first  basic  method  of  cluster  analysis  iS  called 
the  agglomerative  method.  The  measure  of  similarity  used 
is  Euclidean  distance.  The  methodology  begins  with  N 
clusters,  each  object  in  0  is.  a  simple  member  cluster.  The 
method  proceeds  as  the  NxN  distance  matrix  is  searched  for 
the  two  most  similar  entries,  which  are  then  combined  to 
form  a  cluster .  The  method  continues  until  all  objects 
belong  to  one  single  cluster.  This  method  yields  a  result 
which  exhibits  a  strictly  heirarchical  pattern  of  relation¬ 
ships,  in  which  the  number  of  levels  or  ranks  equals  the 
number  of  steps  in  clustering. 

The  form  of  linkage ;  i.e.,  the  criteria  used  to  join 
objects  together  to  form  clusters,  may  vary  from  a  single 
linkage  cluster,  in  which  an  object  is  joined  to  a  cluster  if 
it  has  a  certain  level  of  similarity  with  at  least  one  member 
of  the  cluster,  to  the  complete  linkage  method ,  which 
requires  that  an  object  must  achieve  a  specified  level  of 
similarity  with  all  members,  of  a  given  cluster  before  being 
joined  to  it. 

'2.1.3 .2  Partitioning  Method : 

The  second  method  of  cluster  analysis  is  called  the 


partitioning  method .  The  .partitioning  method  differs,  from 
the  aggiomerative  -method  in  that  the.  solution  does  not 
'portray  a  heirarchical  .relationship  among  the,  entities .  The 
resulting  clusters  obtained  from  a  partitioning  solution-  are. 
discrete  and'  exist  at  a  single  rank-. 

The  method  proceeds  as  follows:  the  user  selects  a 
statistic  to  be  optimized  during,  the  cluster  analysis;  in 
this  case /  measure  (M)>.  All  objects  are  initially  assigned 
to  a  single  cluster  of  N  objects*.  The  user  must  choose  the 
number  of  clusters  (K)  which  are  believed  to  exist  in  the 
data.  The  methodology  must  then  use  some  scheme  to  determine 
K  leader/seed  objects.  These  seed  objects  represent  a 
Kernel  of  objects  abput  which  the  remaining  objects  are 
clustered.  An  object  is  then  assigned  to  a  cluster  with  the 
nearest  centroid.  The  method  then  recalculates  the  centroid 
of  the  cluster  /  and  the  .process  is  then  repeated  until  there 
are  no  membership  changes  which  will  improve  the  overall 
solution.  This  method,  is  iterative  in  the  solution  tech¬ 
nique/  as  an  object  may  actually  change  its  membership  from 
one  cluster  to  another  during  the  process.  The  aggiomerative 
method/  on  the  other  hand,  requires  only  one  pass  through 
the  data  for  a  complete  solution.  The  partitioning  method  is 
more  time-consuming,  but  allows  a  certain  robustness  to  the 
solution  since  each  cluster  is  re-examined  and  members  may  be 
re-assigned.  However,  the  method  requires,  the  specification 
of-  certain  limiting  parameters  "a  priori"  specifically:  the, 


user  must  specify  JC,  final  member  of  clustering,  before 

proceeding  .with  .the  partitioning. 

Another  distinction  among  •partitioning  methods  is 

related  to  the  calculation  of  the  centroid  for.  each  cluster-. 

As  pointed  out  by  Blashfield  and  Aldenderfer, 

"The  combinatorial  methods  require  the  recalculation 

of  the  centroid  of  a  cluster  after  each  change  on 

membership.  Non-combinatorial  methods  calculate 

centroids  only  after  the  complete  pass  has  been  made. 

Therefore#  combinatorial  method  of  control  calculation 
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is  considered  to  be  more  conservative. " 

The  partitioning  method  then  avoids  the  major  weakness  of 
the  agglomerative  method,  since  the  iterative  nature  of  the: 
partitioning  method  allows  early  decisions  regarding  which 
object  is  merged  into  which  cluster  to  be  re-examined  as  the 
algorithm  proceeds.  For  this  reason,  the  partitioning 
cluster  analysis  method  was  selected  for  use  by  Andreau. 

In  order  to  implement  the  partitioning  method  of  cluster 
analysis,  one  is  faced  with  the  following  problems: 

1)  Conversion  of  the  binary  adjacency  matrix  into  a 
similarity  matrix  which  satisfies  the  requisite 
metric  properties. 

2)  Identification  of  the  K  parameters  which  is  the 
number  of  seed  nodes. 

3)  Identification  of  the  actual  nodes  which  are  the 
seed  nodes. 


Blashfield,  p .  9 


-  31  - 

Andreau  investigated  the  use  of  heuristic  graph  decom¬ 
position  techniques,  particularly  the  concept  of  a  "core 
set"  to  solve  the  preceeding  problems .•  The  techniques;  are 
described  in  the  following  section. 


2. 2  Solution  of  the  Cluster  Analysis  Problem- by  the  Graph 
Decomposition  Techniques 

The  purpose  of  this  section  is  to  present  the  tech¬ 
niques  proposed  by  Andreau  for  the  solution  of  cluster  analy¬ 
sis  problems;  specifically' the  conversion  of  the  ad j acency 
matrix  and  identification-  of  partitions  through  the  use  of 
heuristic  graph  decomposition  techniques . 

In  order  to  solve  the  cluster  analysis  problems  prer 
viously  defined,  Andreau  investigated  the  use  of  heuristic 
graph  decomposition  techniques.  The  definitions  of  require¬ 
ments,  interdependencies ,  and  the  adjacency  matrix  still 
apply  to  the  problem  at  hand.  The  following  definitions 
apply  to  graph  decomposition  techniques: 

Core  set;  CS^  associated  with,  a  node  0^  in  the  set 
CSi  :{0j|0j  S.T.  aij  »  1} 
that  is  the  set  of  all  nodes  related  to 
0^,  including  itself. 

Connectivity  of  node  0^: 

Ci  *  !CSjJ  ”  1'  w^ere  l-CS-l  is  defined  as  the 
cardinality  of  set  X  ■» 

Conceptually,  one  is  searching  the  adjacency  matrix  for 


.objects  with  a  high  connectivity  whose  core  sets  do-  not 
interfere  with  each  other..  Once  identified',  these  objects 
form-  the  Kernel  of.  subsets  of  objects  whose  elements  are 
strongly  related.  As  determined  by  Andreu  onCe  the  number 
pf  Kernel  subsets  has  been  identified,  the  remaining  nodes 
can  be  assigned  to  the  subsets  in  which  they  best  fit;  where 
the  measure  of  best  fit  is,  as  previously  defined  by  the  over¬ 
all  measure  (M).  The  actual  procedure  used  to  identify  the. 
subsets,  is.  presented  in  Appendix  B. 

The  procedure  requires  the  "a  priori"  specification  of 
the  parameter  >(K)  which  is  related  to  the  number  of  sub¬ 
graphs,  expected  to  result  from  the  decomposition.  Andreu' s 
experiences  indicated  that  obviously  1  <  K  <  N  where  N 
equals  the  .number  of  nodes  or  objects  subject  to  decomposi¬ 
tion.  Andreu  stated  more  strongly  that  K  should  be  set  at 
a  value  somewhat  higher  than  the  expected  number  of  sub¬ 
graphs,  yet  the  lower  the  value  of  K,  the  more  conservative 
is  the  result  since  fewer  subgraphs  will  be  identified 
considering  the  interferences  among  many  core  sets.  In  order 
to  normalize  the  selection  process  and  to  make  the  facility 
more  robust,  the  selection  process  for  K  was  redefined  as 
follows ; 

K  *• percentage  of  the  maximum  value  of  connectivity, 

,  for  the  entire  graph. 

Note  that  the  value  of  K  has  been  redefined  as  a  percentage 

value  of  C^;  this  implies  that  K  should  be  initially 

""  T  -  . .  ... 

Andreu,  p.125. 
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selected;  es  a  high  value  (80%)  in  order  to  yield-  a  conserva¬ 
tive  result. 

Arid'reu  then  investigated  the  possibility  of  generali¬ 
zing.  the,  definition  of  the.  core  set  as  follows: 

CS :  (0 .  ,0 .  such  that  the  minimum  path 

■  i  ■  "i  j*  ...  ...» 

,0i  *  °j  i  '  where  P  <  1 


Note  that  In  the  case  vrhere  P  *  1,,  uhis  is.  equivalent  to  the. 

previous  definition  -of  the  core  .set;-.  The  definition.-  of  P*1 

is1  required^ in  order  to  specify  a  minimum  path.  A  more 

vq 

complete  explanation  is  offered  by  Andreu?  briefly  the 


point  is  that  the  minimum  path  among  objects  0. , 
as  follows: 


V  °K  is 


When  minimum  path  (0^  >  0^)  5  Minimum  Path 
then  either 


(0j  *  °K> 


1)  Oj,  0K  are  both  adjacent  to  0^ 
or  2)  0.  is  adjacent  to,  neither  0.  nor  .0. 

X  J 


This  is  true  only  in  the  case  where  P*l?  therefore,  Andreu 
uses  P*1  when  computing  the  core  sets  as  previously  defined. 

A  starting  .point  for  partitioning  cluster  analysis  has 
thus  been  identified,  by  the  calculation  and  identification 
of  core  sets  as  follows: 

1)  select  K  *  percentage  value  of  maximum  value  of 

of  connectivity? 

2)  select  the  node  with-  the  maximum  value  of 

connectivity  C^.? 

23,  , 

Andreu^ 
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3.)  select  the  core  set#,  consisting  of  all  objects 
Ch;  for  which,  C.,  >  K  (C^MAX) . 

The-  final  problem  involved  in  generating  a  partitioning 
methodology  was>  to  develop  a  method  to  convert  the  binary 
adjacency  matrix  into  a  similarity  matrix  meeting:  the  metric 
conditions  of  Euclidean  distance#  since  the  single  binary 
coefficients  dervied  directly  from  entries  in  the  adjacency 
matrix  fail  to  meet  these  properties.  '  Andreu  incorporated 
the  "core  set"  concept  previously  introduced  in  order  to 
define  entries  in*  the  similarity  matrix  as  follows-: 


where  *  Similarity  matrix  distance  measure  between 
objects  0^  and  0^ 

CS^  *  Core  set  for  nbe  0^ 

For  the  special  case ,  for  some  pair  of  nodes  0^  and;  0^  such 
that  Sik»0  that  is  (CS^»CS^},  then  it  is  true  that 
for  all  j .  The  nodes  0.  and  0^  are  equivalent  with  respect 
to  the  rest  of  the  graph  as  described  by  the  matrix  S.  For 
cluster  analysis  purposes#  this  special  case  represents  the 
case  for  which  nodes  i  and  k  are  equivalent.  The  pair  is 
collapsed  to  form  a  single  node. 

This  section  has  determined  that  there  are  several 
problems  which  must  be  solved  in  order  to  apply  cluster 
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analysis  .techniques  to  set  decomposition'  .problems;.  Andreu 
'has*  -used  heuristic  graph  decomposition-  techniques  In  order 
to : 

.  Identify  the  K  parameter  which  represents  the  maximum 
value  of  such  -nodes  for  a  given  graph. 

.  Convert  the  adjacency  matrix  defined  by  a  binary 
assessment  of  interrelationships  into  a  similarity 
matrix  meeting  the  metric  properties  of  Euclidean 
geometry. 

The  final  section  of  this  -chapter  will  present  a  stepwise, 
discussion  of  the  application  of  these  techniques  to  the 
decomposition  problem. 

2.3  Decomposition  Methodology 

The  decomposition  problem  was  analyzed  utilizing  a  soft¬ 
ware  package  by  Andreu.  The  package  is  written  in  Fortran 
and  runs  on  the  PRIME  computer  system  of  the  Sloan  School  of 
Management . 

The  features  available  with  this  system  are  as  follows: 

1)  Enter  the  adjacency  matrix  developed  from  the 
requirements  interdependency  assessment.  This 
function  is  performed  using  the  "ENGR"  command. 

2)  Compute  a  distance  matrix  for  the  graph  under  analy¬ 
sis  using,  the  "DIMN"  command.  The  package  actually 
computes  the  distance  matrix  P-1  is  assumed  by  the 
package,  also  it  treats  collapsed  nodes  not  as 
single  nodes. 


3)'  Compute  the 


matrix  from;  the  distance 


matrix  using,  the  "SIMA''  command. 

4)  Generate  an  initial,  -partition,  using  the  "INPA" 
command  to  identify  the  "core  of  subgraphs''  likely 
to  exhibit  high  strength.  The  user  must:  specify 
value  for  the  K  parameter. 

5)  Use  the  clustering  algorithms  to  generate  clusters 
and  return  a  value  for  measure,  strength,  and 
coupling. 

There  are  three  clustering  methods  available  for  use: 

Heirarchical  Clustering  Method  1  -  which  merges  the 
"closest"  pair  of  clusters  measuring  the  distance 
between  two  clusters  A  and  B  by  the  mean  of  the 
distance  between  the  nodes  of  A  and  the  nodes  of  B. 


That  is, 


d  (A,B) 


.  1  2  «  (a,b)  . 

Vb 


where  NA  and  Ng  represent  the  cardinality  of  A  and  B 
respectively,  the  summation  is  over  all  the  elements 
a  e  A  and  b  s  B. 

Heiiarchical  Clustering  Method  2  -  which  merges  the 
pairs  of  clusters  which  lead  to  a  minimum  mean  of  the 
distance  between  all  pairs  of  nodes  in  the  cluster 
resulting  from  the  merge.  That  is, 


minimize  X  * 


_  1  2  (a,a  ) 

—  1  mm*rA s 
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where  N_  =  the  cardinality  of  -the'  set.  merger  A 

Cl’  '  '  **’  - 

a  ,  a  -  s  -‘A.v 

the  summation  is  over  all  pairs  of  nodes:. 

Heirarchical  Clustering  Method  3  -  which  merges  the' 
two  clusters  A  and  B  that  lead  to  a  minimization  of 
the  parameter  y; 

y  “  ipg  U^-k  £s<b*bl> 

where  the  first  summation  is  overall  pairs  of  nodes 
in  A  and  B,  the  second  ..overall  pairs  in  A,  and  the- 
third  overall  pairs  in  B.  This  method  evaluates  each 
clustering  step  as  a  function  of  the*  partition  para¬ 
meters  before  and  after  the  clustering  and,  therefore, 
tends  to  produce  the  best  partitions;  i.e.,  those 
with  the  highest  measure. 

Additional  facilities  exist  in-  the  .software-  package  to 
perform  a.  number  of  additions  and  deletions  from  the  graphs 
and  to  print  out  the  results. 

The  analysis  package  was  designed  to  recognize  a  single 
decomposition  problem  at  a  time.  Therefore,  the  package 
always  deals  with  a  current  graph;  that  is,  the  fundamental 
working  entity  that  the  package  is  currently  working  on.  In 
addition.  Steps  1  through  4  must  be  accomplished  prior  to 
invoking  Step  5.  Any  change  in  the  order  will  generate  a 
system  error. 


The  use  of  the 


is  presented 


/in  Appendices  E  and  H  for  the:  .first  ana  second*  iteration  .of 
the  methodology , 


-CHAPTER  III  • 

SAMPLE  OPERATING  SYSTEM 

The  Sample  Operating  System,  developed  by  Professor 

20 

Stuart  E.  Madnick  and  John  J.  Donovan  as  a  pedagogical, 
tool  to  illustrate  the  basic  functions  of  a  computer  opera¬ 
ting  system,  was  selected  as  the  design  problem  for  analysis. 
The  selection  of  an  existing,  well-documented  system  was 
dictated  by  a  desire  to  insulate  the  decomposition  analysis 
from  any  problems  associated  with  poor  needs  analysis. 

The  Sample  Operating  System  is  composed  of  all  the 
functions  normally  associated  with  a  computer  operating 
system;  however,  due  to  its  strictly  pedagogical  -nature,  it 
has  some  unique  features  a3  well.  It  was  conceptually 
convenient  to  break  the  system  down  with  its  functional 
areas  for  descriptive  and  requirements  definition  purposes ; 
The  following  discussion  will  highlight  the  general  functions 
of  the  Sample  Operating  System. 


3.1  General  Characteristics  of  a  Large  Scale  Computer 
Operating  System 

In  most  general  terms  any  operating  system  is  a  group 
of  progreuhs  within  a  computer  system  which  manage  the 
hardware/software  resources  of  the  computer,  and  thereby 
serve  as  the  interface  between  the  user's  programs  and  the 
resources  of  the  computer. 


Uaaniok  and  Donovan }  p.331. 
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Madnick  and  Donovan  have  defined,  the.  following  entities 
within  a  computer  system: 

user  :,  one;  who. -desires  to  utilize  the  computer  resources . 

job:,  any  collection-  -of  activities  needed  to  complete 
the  work  desired  by  the.  user.  A  job  may  ;be 
further  subdivided  into  steps,  tasks,  or 
processes. 

job  step:  units  of'  work  which  must  be  done  sequentially? 
namely ,  compile,  load,  and  execute. 

task:  a  program  or  job  subdivision  which  is:  the*  basic 
unit  or  work  for  the  .operating  system, 
process  :  a  complete  sequence,  of  instructions  that  are 
functionally/computationally  independent  of 
other  processes. 

The  normal  resource  management  functions  of  the  operating 
system  may  be  generalized  into  the  following  four  functions: 

.  Keep  track  of  a  resource; 

.  Enforce  a  policy  that  determines  which  user  gets  a 
given  resource,  especially  to  resolve  conflicts 
arising  from  competition  for  the  same  resource. 

.  Allocate  a  resource. 

.  Reclaim  a  resource. 

The  functional  resources  of  any  large-scale  computer  system 
may  be  described  as  follows : 

.  Memory  Management  Functions 

.  Processor  Management  Functions 


...  Device.  Management  Functions  • 

Information  Management;  Functions 
The  'definitions,/  management  functions  /  and'  resources,  pre¬ 
viously  defined:  will  be  .adopted  in  order  to  fully  describe 
the  characteristics  of  the;  Sample  Operating  System; 


The  Sample  Operating  System,  as  described  by  Madnick 
and  Donovan,,  is  conceptually  designed  around  a  process, 
recognizing  that  a.  process  is  the  smallest  computational 
entity  arid ,  therefore has  certain  requirements  necessary  for 
its  support.  Thus,  the  Sample  Operating  System  implements 
a  basic  system  nucleus  required  for  a  complete  system;  yet 
it  does  not  include  other  capabilities  such-  as  language 
processors  or  utility ' programs . 

3.2.1  EXTENDED  MACHINE  CONCEPT : 

At  the  most  basic  level,  a  computer  processes  only 
specific  hardware  instructions;  such  as  ADD  and  LOAD.  In  the 
Sample  Operating  System  it  was  necessary  to  provide  the 
basic  functions  for  process  support  as  additional  hardware  - 
like  instructions  at  a  level  above  the  basic  machine  instruc¬ 
tions.  These  instructions  are  called  extended  instructions 
and  are  implemented  by  means  of  the  Supervisor  Call 
Instruction.  These  instructions  are  conceptually  similar  to 
subroutine  calls  which  enable  the  user  to  perform  certain 
resource  management  functions  at  a  higher  level  than  the  bare 
machine.  For  example,  SVC  'H*  is  used  to  halt  a  job  arid 


signal  the  supervisor  process .  Each,  extended  machine 
instruction  calls  a  -handler  routine  and  may  be  user  callable 
The.  hasic  hardware.  Instructions  of  the  machine  combined 
with  the  operating  system  provided  "supervisor  instructions " 
comprise  the  instruction  set  of  the  extended  machine.  The 
Kernel  of  this  operating  system  runs  on  the  bare  machine , 
the  user ' s  programs  run  On  the  extended  machine.  Figure  3 .1 
represents  the  extended  machine  concept. 

3.2. 2  HEIRARCHICAL  MACHINE  STRUCTURE : 

Since  the  Sample  Operating  System  was  intended  to  be 
primarily  a  pedagogical  tool’*  a  layered  system  architecture 
called  heirarchical  operating  system  structure  was  selected 
as  the  basis  for  system  design.  Basically,  the  methodology 
allows  the  segregation  of  major  functions  of  the  operating 
system  into  a  heirarchy  of  capabilities.  Its  major  advant¬ 
ages  include,: 

,  It  is  a  powerful  means  of  proving  the  correctness 
and  maintaining  the  operational  integrity  of  the 
operating  system. 

.  Lower  layers  of  the  system  provide  services  to  higher 
layers  only  via  well-defined  interfaces. 

.  The  modular  structure  enables  the  easy  identification 
of  the  major  functions  Of  the  operating  system. 

In  order  to  implement  the  heirarchical  concept  in  con¬ 
junction  with,  the  extended  machine  concept,  it  was  necessary 
to  define  the:  following.: 

.  Certain  key  functions  needed  by  many  of  the  system 


modules'  could  be  separated  into  an  "inner  extended 

■% 

machine" . 

.  Certain  modules,  which  were  not  utilized  as  key 
functions  yet  still  operating  system  modules ,  Could 
be  separated  out  and  run  on  the  extended  machine,  in 
essentially  the  same  way  as  a  user's  process,. 

It  is,  therefore,  apparant  that  each  module  of  the  operating 
system  must  be  identified  as  running,  either  in  the  inner 
extended  machine,  the  outer  extended  machine,  or  as  a 
process. 

For  further  clarification,  Madnick  and  Donovan  have 
generalized  the  inner/outer  extended  machine  concept  into 
levels  of  the  extended  machine,  and  all  operating  system 
functions  that  run  as  processes  can  interrelate  and  are 
generalized  into  layers  of  processes.  The  Kernel  of  the 
operating  system  then  is  all  these  modules  that  reside  in  the 
extended  machine  and,,  therefore,  do  not  include  operating 
system  processes. 

For  purposes  of  the  Sample  Operating  System  design,  the 
basic  functions  of  the  operating  system  have  been  placed  in 
the  Kernel,  and  as  many  tasks  of  the  operating  system  as 
possible  have  been  placed  into  separate  system  processes. 

In  this  heirarchical  implementation,  we  impose  the  following 
restriction:  a  given  level  is  allowed  to  call  upon  the 
services  of  lower  levels  only;  i^e. ,  those  levels  closer  to 
the  bare  machine.  This  restriction  requires  well-defined 
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interfaces  and  synchronization  schemes  throughout  the  Sample, 
Operating  System. 

Figure  3.2  graphically  portrays  the  heirarchical 
operating  system  structure. 

The'  three  concepts  implemented  for  the  design  of  the 
Sample  Operating  System  design*  (that  is,  process  focus, 
extended  machine  concept,  and  heirarchical  structure)  have 
evolved  into  a  system  with  the  following  features: 

.  .process  synchronization  semaphore.,  used  extensively 
for  resource  allocation  synchronization; 

.  message-  system  for  interprocess  communication ; 

.  five  levels  and  layers  of  the  Sample  Operating  System: 
Levels'  -  Process  Management,  lower  module 
Memory  Management  module 
Process  Management,  upper  module 
Layers-  -  Device  Management  module 
Supervisor  Process  module 

A  brief  description  of  the  function-  of  the  levels  and  layers 
is  provided  to  further  clarify  the  structure,  of  the  Sample- 
Operating  System. 

3.2.3  PROCESS  MANAGEMENT,  LOWER  MODULE: 

This  module  enables  the  Sample  Operating  System  to 
support  multiprogramming  and  the  basic  system  primitive 
operations  required  for  interprocess  synchronization. 

The  basic  primitives  as  previously  described,  are  the 
so-called  P-V  operations.  Both  operations  act  on  a  semaphore 
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3.2.5  .PROCESS.  MANAGEMENT.,.  UPPER  MODULE: 

This  module  •provides  the'  routines  for  the  control  of 
processes;  i.e. ,  process  creation  and  deletion.  The  module 
also^provides  for  interprocess  communication  with  buffered, 
messages.  This  module  was  split  from  the  Process  Management, 
lower  module  since  it  depends  on  the  functions  of  memory 
management  to  allocate  or  free,  memory  areas  to  store  system 
information  concerning  each  process  and  to  provide  temporary 
buffers  to  store  interprocess  communication  messages:.. 

3.2.6  DEVICE  MANAGEMENT  MODULE: 

This  module  runs  as  a  separate  process;  hence,  it  is 
considered  a  layer  of  the  operating  system.  There  is  one 
device  management  module  per  device  which  provides  the 
routines  necessary  to  issue  the  appropriate  input/output 
commands  to  external  devices.  This  module  depends  heavily 
upon  the  interprocess  communication  message  facility  to  issue 
I/O  and  to  interpret  the  status  information  fOr  a  return 
message.  Device  management  for  this  service  is  simple  since 
all  devices  are  dedicated  and  consist  only  of  card  readers 
and  line  printers. 

3.2.7  SUPERVISOR  MODULE : 

The  supervisor  module,  also  runs  as  a  separate  process 
of  the  Sample  Operating  System;-  specifically,  one  per  job 
stream.  The  supervisor  provides  interfacing  for  all  the 
routines  needed  to  run  a  job.  In  particular,  the  supervisor 
process  is  responsible  for  coordinating  the  following;: 


1)  Reads  in  a  job  stream. 

2) '  Allocates  a  partition,  of  memory  for  each  job.  in 

sequence . 

3)  Creates!  and  starts  the  appropriate  device  manage¬ 
ment  process. 

4)  Loads  the  user's  object  deck  into  the  partition. 

5)  Creates  and  starts  a  process  in  the  given  partition. 
Since  the  supervisor  process  is  not.  needed  until 
the  user' s  job  ends,  it  stops  running  and  waits  for 
a  message  signalling  completion  of  the  user's  job. 

6)  Finally,  when  completion  is  signalled,  the  super¬ 
visor  cleans  up  by  destroying  the  allocated  parti¬ 
tion  of  memory,  and  goes  to  the  next  job  input 
stream. 

3.2.8  USER'S  PROGRAMS  AND  PROCESSES: 

Initially  the  Sample  Operating  System  creates  a  single 
process  for  each  job;  however,  the  user  is  free  tip  create 
additional  processes  to  run  in  parallel.  The,  user's;  job  runs 
in  problem  state  with  non-zero  protection  key  assigned,* 
thereby,  restricting  user  access  (to  privileged  instructions 
and  memory  areas  external  to  the  user's  allocated  partition) . 

The  nucleus  routines,  such  as  P-V  operations,  are 
restricted  from  the  user  and  cannot  be  accessed  by  the  user's 
job.  However,  the  interprocess  communication  message 
facility  is  available  to  the  user  and  can  be  utilized  for 
interprocess  synchronization  of  user  processes. 


3i3  Summary 

The  basic  design:  philosophy  of  the  Sample  Operating 

--  _  _  ,p 

System  and;  a  functional  description  of  the  major  modules  has 
•been  presented  as  the  system  is  currently  configured ^  The 
next  two  chapters  will  first  define  the  requirements  as  they 
exist  for  the  Sample  Operating  System;  and  second ,  assess 


the  interrelationships  among  these  requirements . 
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CHAPTER  TV 

REQUIREMENTS  DEFINITION 

The  purpose  of  this;  chapter  is  to  describe  the  method¬ 
ology  of  the  requirements  definition:  for  the  Sample  Operating; 
System.  The  requirements  were,  defined  from  a  description,  of 
the  Sample  Operating  System  and  program  listings  as  provided 
by  Madnick  and  Donovan,  subject  to  certain  guidelines 
established  .by  Andreu  to  insure  that  as  much  as  possible 
the  requirements  are  defined  in  a  clear,  correct,  and 
concise  manner. 

It  must  be  stated  at  the  outset  that  requirements 
definition .was  the  most  time-consuming  portion  of  this 
analysis.  The  definition  phase  was  repetitively  iterated  as 
requirements  were  defined  more  clearly,  make  less  ambiguous, 
corrected,  discarded,  combined,  separated,  and  new  requires 
ments  added  continuously.  Since  one  can  become  completely 
embroiled  in  the  problem,  it  is  essential  that  the  require¬ 
ments  be  reviewed  periodically  by  an  interested  third  party. 

The  initial  methodology  for  .requirements  definition  was 
23 

proposed  by  Andreu  and  was  based  on  his  experience  with 
the  problem.  Andreu  began  with  a  set  of  requirements  for  a 
database  management  system  and  sought  to  refine  those 
requirements  as  they  existed.  For  the;  Sample  Operating 
System,  however,  no  such  precise  list  of  requirements 

23  r"  '  'v  —  "  ~  /  ’  *i;  r  - " 

Raphael  Andreu,  "An  Exercise  in  Software  Design:  From 

Requirements  to  Design  Problem -  Structure" ,  MIT'  Sloan  School 
unpublished  report  (June,  19.77),  pp.3-15 ; 


existed.  Therefore,  it-,  was  necessary  to  draft  a  set-  of 
requirements  from  a  textual  description  of  what  the  system 
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does  using-  program  listings,  to  resolve  unclear  issues. 
Consequently,  the  Andreu  methodology  was  supplemented  with 
additional  guidelines  based  on  these  experiences  in  defining 
requirements . 

The  following  section  will  define  the  methodology  and 
by  way  of  example ,  demonstrate  what  constitutes  good  or  poor 
definitions  of  requirements . 

4.1  Requirement  Definition  Methodology 

4.1. 1  DEFINITION  CLARITY : 

Requirements  should  be  stated  clearly  and  concisely. 

It  is  conceptually  difficult  to  deal  with  requirements  which, 
are  verbose  or  deal  with  more  than,  one  specific  issue.  In 
addition,  requirements  interdependencies  are  assessed  on  a 
one-for-one  basis.  Therefore,  each  requirement  for  the 
Sample  Operating  System  was  limited  to  a  single  sentence, 
covering  only  one  issue.  The  requirements  for  the  Sample 
Operating  System  are  presented  in  Appendix  G,  and  each 
requirement  statement  is  followed  by  a  definition  of  the 
requirement  and  a  statement  of  implications  of  that  require¬ 
ment  for  the  design  of  the  system.  This  format  was  valuable 
for  it  enabled  a  -single  sentence  requirement  definition 
statement,  yet  it  facilitated  further  amplification  of  the 
design  requirement  which  was  very  helpful  in  the  inter- 
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dependency  assessment  phase. 

4.1.2  SCOPE  OF  DEFINITION: 

■  Requirements  must  not  be  stated  in  very  general  terms, 
or  in  terms  dealing  with  issues  beyond  the  scope  of  design. 
For  example :  The  operating  system  must  be  capable  of 
maintaining  memory  resources .  This  is  a  general  state¬ 
ment  characteristic  of  all  operating  systems  by 
definition.  This  statement  does  nothing  to  further 
define  characteristics  of  the  Sample  Operating  System. 

In  addition >  no  requirements  were  defined  for  the 
following  functions:  system  reliability,  documentation, 
and  system  security,  simply  because  none  of  these 
issues  were  addressed  as  needs  of  the  Sample  Operating 
System,  and,  therefore,  were  beyond  the  scope  of  the 
design. 

4.1.3  IMPLEMENTATION  INDEPENDENCE : 

24 

As  stated  by  Andreu  and  Madnick  requirements  should 
not  specify  an  implementation  scheme  that  may  be  used  in  the 
design  of  the  system,  dearly  a  requirement  which  specifies 
how  a  requirement  is  to  be  implemented  biases  the  design 
process.  Specifically,  such  a  procedure  precludes  the 
design  from  considering  alternative  solutions  to  a  given 
design  problem.  The  specific  implementation  scheme  may  be 
appropriate  within  its  limited  realm  of  consideration,  but 
may  not  be  optimal  in  the  context  of  the  overall  design 

problem.  Finally,  any  implementation  scheme,  specified 
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"a  priori”  inevitably  affects  other  .requirements  in  other 
stages  of  the  design  process.  The  criteria  for  requirements 
definition  is  simply  that'  the-  requirement  definition  must- 
state  only  what  is  to  be  done  and  not  how. 

For  example :  the.  statement,  "A  process  can  issue  a  call 
to  read1  the  text  and  name  of  the  message  sender" ;  f his 
violates  the  guidelines  since  the  statement  defines  the 
means  of  implementation .  The  requirement  focuses  on 
how  a  process  recognizes  the  text  and  name  of  a  message 
sender,  rather  than  what  was  intended. 

Therefore,  the  requirement  was  re-written  as:  "The 
receiving  process  may  read  the  name  and  text  from  the 
originator" . 

4.1.4  SYSTEM  STRUCTURE  INDEPENDENCE : 

Any  definition  of  requirements  should  avoid  biases 

toward  pre-established  assumptions  about  the  structure  of  the 

25 

final  design  according  to  Andreu. 

This  guideline  is  very  subtle  in  its  application,  and 
represented  the  most  difficult  guideline  to  fulfill  since 
the  Sample  Operating  System  had  been  designed  and  was 
described  in  terms  of  its  final  structure.  Conceptually, 
anyone  seeking  to  define  a  non-trivial  system  must  organize 
his  thoughts  in  some  manner  to  avoid  total  confusion.  The 
most  logical  framework  for  organization  is  in  terms  of  the 
functional  requirements  of  the  system.  The  most  general 
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functional  requirements  for  an  operating,  system  focus  upon 
the  role  as  a  resource  manager  of  memory ,  processors, 
devices,  and  files .  -Therefore:,  one  tends  to  define  require*?' 
ments  in  the  framework,  and  the  trivial  decomposition 
solution  would  define  four  distinct  subproblems  which 
correspond  to  those  functional  requirements.  Clearly,  such 
-a  solution  would  offer  no  new  insights  into  the  structure  of 
the  design  problem. 

For  example >  the  requirement  "This  operating  system 
must  be  pedagogical  and  modular ly  structured",  was 
considered  to  violate  the  guideline.  The  Sample 
Operating  System  was  designed  to  be  pedagogical. 

Although  it  is  generally  recognized  that  the  most 
effective  method  of  achieving  pedagogical  clarity  is 
through  modular  design,  such  a  statement  is  constraining 
upon  the  system  designers  and,  therefore,  was  re-written 
as  follows:  "The  operating  system  must  be  designed  as 
a  pedagogical  tool".  The  resulting  decomposition  of 
the  design  requirements  should  indicate  what  degree  of 
modularity  was  achieved  in  the  actual  design. 

4.1.5  INDEPENDENCE  AMONG  REQUIREMENTS: 

This  guideline  implies  that  all  requirements  must  be 
semantically  independent?  namely,  that  redundant  require¬ 
ments  must  be  eliminated. 

For  example:  the  two  requirements  "Basic  system 
primitives  and  certain  routines  are  restricted  from  the 


user,  the  use  of  which,  will  generate  an  error"  and 
"The  operating'  system:  shall  protect  itself  from  the  use 
of  supervisor  routines'  by  the  .user"  are  redundant;  the 
former  being,  implied  by  the  latter.  The  former 
requirement  was,  therefore,  eliminated.. 

4.1.6  SIMPLICITY: 


Each  requirement  should  address  one  well-defined 
capability  that  the  final  design  is  to  demonstrate.  The 
purpose  of  the  decomposition  methodology  is  to  assess  inter¬ 
dependencies  among  individual  requirements,  and  to  group 
similar  requirements  together.  Therefore,  grouping  require¬ 
ments  by  definition  masks  the  decomposition. 

Many  requirements  were  originally  defined  with  multiple, 
capabilities  *  It  was  necessary,  therefore,  to  separate  each 
capability  with  a  separate  requirement. 

For  example:  the  following  requirement,  originally 
written  as  a  single  requirement,  was  separated  into 
four  distinct  requirements:  "A  process  synchronization 
mechanism  must,  be  provided:; 

1)  to  serve  as  a  lock  on  a  database. 


2)  for  timing  of  synchronous  processes. 

3)  for  synchronization  of  the  message  facility. 

4)  to  lock  a  device. 


4,1.7  NO  STAND-ALONE  REQUIREMENTS: 


Requirements  which  are  only  remotely  concerned  with  the 
final  design  should  be  avoided;  for  example-,  features  which 
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may-  be  added  to  an  operational  system  at  a  later  time 
illustrate- this  pciint. 

For  example;  The  requirement,.  "The  supervisor  process 
must  be  modularized  so  that  improvements  to  the  system 
can  be  easily  accomplished" ,  satisfies  this  guideline . 
The  requirement  indicates  that  improvements  to  the 
system  are  anticipated;  yet  it  does  not  limit  the 
requirement  by  specifying,  what  improvements  will  be 
made  later. 

4.1. 8;  PLAUSABILITY.i 

Naturally,  a  requirement  should  avoid  the  impossible; 
therefore,  statements  shall  be  eliminated  which  imply 
requirem'ents  which  are; 

.  not  available  with  current  technology; 

.  in  violation  of  fundamental  physical  requirements; 

.  clearly  violating  other  requirements. 

For  example;  The  requirement,  "The  input/output 
devices  are  limited  to  card  readers  for  input  job 
streams  and  line  printers  for  output",  implies  that  no 
spooling  system  is  available.  This  in  turn  dictates 
that  job  scheduling  be  accomplished  on  a  first-come, 
first-served  basis. 

Initially,  it  was  felt  that  such  non-capabilities 
(i.e.,,  lack  of  spooling  capability  and  lack  of  file 
system)  should  be  explicitly  stated  as  a  requirement 
rather  than  inferred.  However,  the  assessment  nf 


.requirements  for  facilities!  which,  do  not  exist  would  . 
have  been  difficult  to  accomplish.  Therefore ,  the  'lack 
of  a  certain  capability  was;  not  addressed  in  require¬ 
ments  definition;. 

In  addition  to  the  previous  guidelines  established  by 
Andreu,  the  following  additional  guidelines  were  developed. 
4.1.9  SEMANTIC.  INTERPRETATION : 

The  requirements  should  be  defined  in  a  manner  that 
limits  semantic  interpretation.  This  guideline  resulted 
from  an  examination  of  the  various  "problem  statement 
languages”  which  are  currently  being  investigated.  Stating 
requirements  formally,  in  a  problem  language  statement, 
could  not  only  reduce  the  ambiguity  of  the  requirement,  but 
aid  in  the  interdependency  assessment  phase.  Although  no 
specific  language  was  employed  for  requirement  definition, 

the  basic  structure  and  intent  of  a  rigorous  definition 

*• 

language  was  used  to  define  the  requirements;  specifically, 
the  requirements  were  defined  as  follows : 

1.  Utilize  generally  understood  terminology;  for 
example,  "reclaim  memory  resources"  versus 
"garbage  collection".  Reference  to  functions  was 
by  formal,  terminology  job  scheduler. 

2 •;  Avoid  terms  which  are  not  commital;  for  example, 
"operating  system  must  supply  ...  "  instead  of, 
"operating  system  may  or  should  be  capable  of . , . " 

3.  Recognize  the  distinction  between  existence 
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statements  and  performance  statements .  For  example , 
the-  requirement*  "The  process  scheduler  must  time- 
slice- CPU  usage  among  ready  processes  to  achieve 
multi-programming" ,  implies  the  existence  of  some 
time,  quantum. 

The  actual,  performance  requirement  is  stated 
separately  as  "A.  process  must  be.  blocked,  and  con¬ 
trol  released  to  the  process  scheduler  when  a  time 
quantum  of  50  ms  is  exceeded". 

Limitations  implied  by  existence  statements  must  be  made 
explicit,  in  a  .performance  statement. 

4.1.10  SCOPE  OF  REQUIREMENT  DEFINITION: 

The  requirements  must  be  defined  at  the  same  level  of 
scope.  The  customer,  in  this  case  being  the  person  for  whom 
a  system  is  designed,  must  have  a  macro-level  objective 
which  the  system  must  be  designed  to  satisfy.  P.  Mandel  and 
C.  Chryssostomidis  state: 

"The  objective  of  most  problems  that  man  is  capable  of 
conceiving  or  is  interested  in  solving  is  that  of 
choosing  the  course  of  action  which  subject  to  pre¬ 
vailing  constraints,  optimizes  the  'well  being'  of  all 
concerned."26 

The  following  concepts  have  been  identified  at  the  outset  of 
the  design  process. 

.  An  objective  function  to  be  optimized  for  the  design 
process. 
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Mandel  and  Chrussostomidia ,  p.SS. 
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.  Prevailing  constraints/  which  impose  limitations  upon 
the  designer* 

.  Requirements  flow  directly  from  the  customer  in 
response  to  the  overall  objective  of  the  system  design. 
The  objective  function  usually  takes  the  form  of  a  multi- 
matrical  expression  to  be  optimized  and  for  most  large-scale 
computer  systems >  consists  of  the  maximization  of  throughput 
or  minimization  of  response  time. 

The  objective  function  of  the  Sample  Operating  System 
is  pedagogical  clarity  and,  therefore,  it  is  very  difficult 
to  state  that  the  objective  Junction  has  not  been  fulfilled. 
For  the  purposes  of  the  design  of  the.  Sample  Operating 
System,  a  design  philosophy  has  been  identified  which 
defines  the  design  criteria  for  the  system  on  a  macro-level. 
The  requirements  that  comprise  the  design  philosophy 
influence  each  of  the  remaining  requirements  and,  therefore, 
were  not  incorporated  into  the  assessment  process. 

The  design  constraints  usually  serve  to  limit  the 
permissable.  range  of  solutions  of  the  problem.  The 
constraints,  then,  impose  limitations  oh  the  designer  which 
affect  the  global  design  problem.  In  the  Sample  Operating 
System,  certain  hardware  constraints  were  imposed  "a  priori" 
upon  the  design  problem.  Specifically,  the  operating 
system  must  be  designed  to  run  on  IBM/360  hardware.  The 
implications  of  this  constraint  affect  certain  basic 
functions  of  the  operating  system.  Since  the  design  con¬ 
straints  have  been  specified  "a  priori" >  such  constraints 
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have  been  separated  from  the  remaining  system  requirements 
and  were  not  incorporated  into  the  assessment  process  since 
the,  constraints,  represent,  limitations  on  system  design,. 

Finally,  the  system  requirements  are  defined  in  direct 
response  to  the  customer's  objectives.  The,  system  level 
requirements  must  be  defined  at  a  level  below  the  most 
general  of  system  level  statements yet  remain  above  the 
level  which  begins  to  limit  the  options  of  the  designer. 


4,2  Summary 

The  requirements  for  the:  Sample  Operating  System  were 

defined  in  two  iterations .  The  preliminary  set  of  require- 

* 

ments  was  defined  initially  and  are  presented  in  Appendix  C. 
The  second  or  final  requirements  set  was  defined  after  the 
initial  application  of  the  decomposition  methodology  and 
are  presented  as  Appendix  G. 


CHAPTER  V 

INTERDEPENDENCY  ASSESSMENT  METHODOLOGY 

The  purpose  of  this  chapter  is  to  establish  the  guide-? 
lines  that  were  used  for  the  assessment  of  interdependencies 
between  pairs  of  requirements.  The  assessment  was:  conducted 
on  a  pair-wise  'basis  according  to  the  following  definition 
of  interdependence. 

Two  requirements  are  termed  interdependent  of  the 
design  decisions  made*  with  respect  to  one  requirement  con¬ 
straint#  or  influence  the  definition  of  the  second  require¬ 
ment.  Thus,  the  interdependent  relationship  between  two 
requirements  can  be  viewed  in  two  ways : 

Supportive :  in  the  sense  that  the  two  requirements 
are  compatible;  meeting  one  requirement  will  help 
to  satisfy  the  other  as  well. 

Conflicting:  the  interdependency  is  such  that  some 
trade-offs  must  be  established  between  the  two 
requirements  in  the  later  stages  of  the  design 
process. 

The  result  of  the  assessment  process  is  the  decomposition 
of  the  global  system  requirements  into  a  number  of  sub¬ 
problems  >  which  ideally  will  be  a  collection  of  highly 
dependent  requirements.. 

interdependency  Assessment  Methodology 
The  methodology  for  interdependency  assessment  proposed 
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by  Andreu  consists  of  a  pair-wise  assessment  of  the:  inter¬ 
dependencies  between  requirements  by  the  generation  of 
"conceptual  models"  within  whose  context  the  assessment  can 
be  made.  The  purpose  of  generating  a  conceptual  model  for 
the  assessment  process  is  to  have  a  specific  mental  frame¬ 
work  so  that  the  process  is  consistent  and  conceptually 
rigorous *  The  following  guidelines  have  been  proposed  by 
Andreu,  for  the  generation  of  conceptual  models : 

.  Scan  the  requirements  in  order  to  develop  loose 
conceptual  models  of  the  system. 

.  Supportive  requirements  can  be  identified  by 
visualizing  a  conceptual  model  in  which  a  possible 
implementation  would  allow  for  common  processing  in 
the  final  system  in  order  to  meet  the  two  require¬ 
ments  involved. 

.  Supportive  requirements  can  be  identified  in  cases 
where  two  distinct  requirements  call  for  similar 
functions  to  be  performed  in  different  circumstances 
in  the • final  design . 

.  Conflicting  requirements  can  be  identified  by.: 

...  searching  for  deadlocks 

i .  identifying  when  a  given  requirement  imposes 

limitations  or  constraints  in  other  requirements. 
..  identifying  the  need  for  "symmetric"  processing; 
that  is,  additional  processing  to  meet  a  given 
requirement  is  necessary. 
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The  procedure  of  assessing  all  the  interdependencies 
for.  a  large  system  can  become  burdensom.  Therefore, 

Andreu,  has  proposed  a  set  of  procedural  guidelines,  based 
on  his  experiences,,  which  were  helpful  in  avoiding  some  of 
the  pitfalls  of  this  time  consuming  process,. 

;  Establish  an  order  for  the  assessment  to  be  made. 

■*  Write  down  conceptual  models:  as  they' occur. 

.  Avoid  going  backwards  to  renew  an  assessment  made 
previously.  Finish  the  assessment  process  arid  then 
return i 

.  If  the  assessment  of  similar-  requirements-  becomes 
confusing  change,  to  a  different  set. 

.  If  no  conceptual  models  are  apparent  skip  the 
assessment  until  one  is  available. 

.  If  one  feels  uncertain-  or  lacks  confidence  in  the 
assessment  process;  stop,,  and  come  back  to  it  later. 

.  A  second  assessment  pass  is  useful,  since  it  enables 
one  to  employ  new  conceptual  models  and  to  review  the 
assessments  which  have  been  previously  established. 

In  addition  to  the  guidelines  established  by  Andreu  the 
following  additional  guidelines  were  identified. 

In  the  case  where  the  assessor's  experience  is  lacking, 
the  results  of  the  assessment  process  should  be  reviewed  by 
another  interested  third  party  in  order  to: 

.  verify  the  conceptual  model. 

.  verify  the  nature  of  the  interdependency. 

.  verify  the  resulting  adjacency  matrix. 
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In  order  to  define  a  more  rigorous  conceptual  model 
for  the.  assessment  process',  the  following  assessment 
template  was  imposed  upon  each  assessment: 

1.  Does  the  first  requirement  conflict  with  the 
implementation,  of  second  requirement.,  causing 
deadlocks,  symmetric  processing,  or  imposing 
limitations?  For  example.,  the  first  requirement,. 
"System  resources  must  be  allocated  to  a  job  prior 
to  being  allocated  a  processor" .  The  user 
resources  (i.e.,  processor)  are  allocated  at  the 
user  level,  and  the  system  resources  are  allocated 
at  job  level,  which  requires  symmetric  processing.. 

2.  Does  the  first  requirement  support  the  implementa¬ 
tion  of  the  second  requirement  by  common  processing: 
or  do  they  call  for  similar  functions  to  be  per¬ 
formed  in  different  circumstances?  For  example, 
the  first  requirement,  "System  resources  must  be 
allocated  to  a  job  prior  to  the  job  being  made 
eligible  to  run"  is  supported  by  "the  supervisor 
process  must  schedule  jobs  and  prepare  the  jobs’  for 
execution".  In  this  case,  the  supervisor  process 
controls  the  allocation  of  resources  for  each  job, 
preparing  'them  for  execution. 

5,2  Summary 

A  pair-wise  interdependency  assessment  was  conducted 


requirement  defined.  Since  an  interdependency  is  symmetric , 
in  the  sensr*  that  an  interdependency  between  requirement  #8 
and  #30  implies  an  interdependency  between  #3Q;  and  #8:. 
Therefore ,  each  requirement  was  assessed,  with  the  require¬ 
ments  that  followed  it.  At  the  time  of  assessment,  an  indi¬ 
cation  was  made  whether  the  interdependency  was  supportive  or 
conflicting,  and  a  brief  statement  of  the  rationale  for  the 
interdependency  was  made. 

As  was  the  case  for  requirements  definition,  the 
interdependency  assessment  process  took  place  in  two 
iterations .  The  preliminary  interdependency  assessment  is 
presented  in  Appendix  D,  and  the  final  interdependency 
assessment  is  presented  in  Appendix  H, 
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CHAPTER.  VI 

FIRST  ITERATION:  OF  THE  DESIGN  PROBLEM 

The  interdependencies  assessed  between:  pairs  of  require¬ 
ments  were  formed  into  an  adjacency  matrix  and  input  into 
the  software  analysis  package  developed  by  Andreu .  This 
chapter  will  present  an  analysis  and  discussion  of  the 
resulting  problem  structure.  The  analysis  and  discussion 
will  consist  of  the  following  sections: 

.  An  analysis  of  the  resulting  problem  structure  for 
the  first  iteration. 

.  Discussion  of  the  main  subproblems. 

.  Discussion  of  the  subproblem3  generated  by  a  second 
decomposition. 

*  Relationships  amonq  the  main  subproblems.. 

.  Motivation  for  a  second  iteration. 

6 . 1 .  Analysis  of  Problem  Structures 

A  total  of  sixty-five  requirements  were  input  with  the 
software  analysis  package  for  decomposition.  Appendix  E 
presents  a  copy  of  the  output  of  the  analysis  and  will  be 
frequently  referred  to  during  the  analysis.  The  analysis 
provided  as  follows: 

First,  the  data,  in  the  form  of  links  (interdependen¬ 


cies)  between  nodes  (requirements)  was  verified  by  checking 
that  all  assessed  interdependencies  were,  in  fact,  present. 
This  was  accomplished  using  the  "NOLK"  command. 
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Second:/,  all  isolated  nodes.:  those  nodes  with  no 
interconnecting  links  were  identified^  As  a-  procedural 
convenience,,  the  initial  graph  was  input  with  several  extra 
nodes .  It  is  possible  to  delete  -nodes  during  the  analysis , 
but  no  new  nodes  may  be  added.  Therefore,  in  order  to 
enter  neW  nodes,  one  must  redefine  the  entire  graph.  To 
avoid  this  time-consuming  process ,.  extra  nodes  were  padded 
into  the  graph,  and  the  graph  saved  with  the  padded  nodes. 

A  working  copy  of  the  graph  was  generated  by  identifying  and 
deleting  isolated  nodes  and-  then  saving  the  temporary^ 
working  copy. 

6.1.1  MAIN  SUBPROBLEMS: 

The  adjacency  matrix  was  decomposed  utilizing  the 
steps  outlined  in  section  2 . 3  and  the.  results  including  a 
heirarchical  tree  are  presented  in  Appendix  E.  The  design 
requirements  decomposed  into  six  clusters  or  main  sub- 
problems  (abbreviated  at  MS) ,  of  twenty  to  four  members  each. 
The  decomposition  was  generated  using  the  so-called 
heirarchical  clustering  method  -3,  the  following  evaluation 
parameters  resulted: 

Strength:  1.9864 

Coupling:  .8674 

Measure:  1.1119 

Strength  was  defined  as  a  normalized  evaluation  of 
subset  internal  coherence;  that  is,  how  tightly  coupled  the 
nodes  in  a  given  subgraph  are.  Coupling  is  defined  as  an 
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evaluation  of  the  extent  to  which  two  subgraphs  are  inter¬ 
dependent.  Measure  equals  strength  minus  coupling.  The. 
evaluation  parameters  obtained  are  important  in  a  relative 
sense ,  since  there  is  no  absolute  value,  of  any  parameter 
which  indicates  a  good  decomposition.  A  comparison  of 
strength  and  coupling  was  made  to  make  some  statements  of  the 
decomposition.  A  coupling/strength  ratio  *  .43  was  deter¬ 
mined  indicating  that  the  coupling  between  subgraphs  was 
nearly  half  the  measure  of  internal'  coherence.  This 
indicates  that  the  subgraphs  are  internally  coherent  (high 
strength  value)  and  still  have  a  reasonable  degree  of 
coupling.  Whereas  a  small  coupling  value  would  indicate  that 
the  subgraphs  were  relatively  decoupled. 

In  order. to  further  investigate  the  coupling  evaluation 
Andreu  suggests  a  second  decomposition  in  which  each  main 
subproblem  is  treated  as  an  entire  graph  and  decomposed  into 
subproblems.  Since  the  coupling  parameter  increases  as 
subproblems  are  defined,  and  strength  remains  constant,  the 
decomposition  of  the  main  subproblems  into  subproblems 
decreases  the  overall  partition  measure.  If  the  coupling 
parameter  between  main  subproblems  is  low  originally,  the 
main  subproblems  are  fairly  disjoint  and  a  second  decompo¬ 
sition  should  be  investigated.  In  the  ideal  case,  a  main 
subproblera  may  exhibit  such  internal  coherence  (high 
strength)  that  it  does  not  decompose,  into  subproblems.  This 

27  “  1  ~  '  ~  *  ”"  *  "  '  ,  . 
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-  70  - 

became  the  motivation  for  a  second  decomposition,*  that  “is, 
a  main  subproblem  was  considered  well-defined  if  no  decom¬ 
position-  resulted.  Therefore,,  a  second  decompsoition  of 
each  main  subproblem  was  performed?,  the  results  are  presented 
in  Appendix  E. 

6.2.2  SECOND  DECOMPOSITION  STEP; 

Each  main,  subproblem  resulting  from  the  original  decom¬ 
position  was  individually  decomposed  as  follows : 

1.  A  separate  graph  was  defined  for  each  main  sub¬ 
problem  by  eliminating  all  nodes  external  to  the  MS 
under,  analysis.  This  was  accomplished  using  the 
"DEMO"  command.  The  nodes  of  the  current  are  re¬ 
numbered  at.  this  point,  which  required  rather 
awkward  collating  schemes  to  keep  the  original  set 
of  requirements  synchronized  with,  each  new  sub¬ 
graph. 

2.  Each  MS  was  decomposed  according  to  the  methodology 
of  section  2.3. 

Of  the  six  MS  originally  defined  only  two, 

MS  2:  and  MS  3  further  decomposed. 

6.1.3  ANALYSIS  METHODOLOGY ., 

In  order  to  analyze  the  structure  of  the  design  problem 
implied  by  the  decomposition  technique,  it  is  useful  to 
investigate  the  following  entities; 

,  Elements;  requirements  contained  within  a  given 
subset. 


.  External  Interdependencies;  links  that  exist  among 
the  elements  of  different  subsets.  The  command 
"PRLK"  was  useful  in  identifying  the  external  links ; 
Recalling'  the  core  set  identification  process  >  certain  nodes 
were  identified,  as  seed  nodes;  about  which  other,  nodes  were 
clustered .  In  order  to  identify  the  main  focus  of  each 
cluster,  one  examines  the  requirements  involved  in,  the 
largest  number  of  interdependencies?  i.e. ,  the- node  in  an  MS 
with  the  largest  number  of  links .  It  is  assumed  that  this 
is  the  seed  node  for  the  MS  and  is,  therefore,  related  to- 
the  main  focus  of  that  MS.  It  is  also  noted  that  a  given 
main  subproblem  may  have  several  nodes  with  nearly  the  same 
number  of  links  which  could  be  called  equivalent  seed  nodes. 
A  closer  examination  of  these  nodes  must  be  undertaken  to 
determine  the  nature  of  such  a  main  subproblem. 


6 . 2  Main  Subproblems 

The  problem  structure  resulting  from  the  application  of 
the  decomposition  methodology  is  presented  in  Figure  6.1. 

The  problem  structure  was  interpreted  as  composed  of  the 
main  subproblems,  depicted  as  blocks  in  Figure  6.1  and  the 
subproblems,  generated  by  a  second  decomposition,  depicted 
as  circles  within  the  parent  MS;  The  interdependencies 
among  the  elements  of  different  subproblems  were  generalized 
into  interfaces  which  are  required  in  design  between  sub¬ 
problems  , 


The  interpretation  of  main  subproblems  should  be 
intuitive  if  the  MS  are  well-defined.  Since  each  MS-  was 
built  around  a  Certain  seed  node,  interpretation  became  a 
problem  of  identifying  the  node  and  understanding  how  the 
Other  member  nodes  were  built  around  it. 

The  more  interesting  part  of  the  interpretation  was  to 
identify  the  counter-intuitive  or  non-obvious  results. 

These  results  suggested  a  structure  of  the  design  that  was 
not  apparent  at  the  outset  or  perhaps  errors  in  the  analysis. 
In  either  case>  it  was  the  identification  of  non-in tuitive 
results  that  represent  the  value  of  the  process. 

The  following  discussion  will  highlight,  the  general 

and  specific  characteristics  of  the  design  structure 

/ 

indicated  by  the.  decomposition  methodology. 

The  decomposition  methodology  generated  six  main  sub¬ 
problems  at  the  end  of  the  first  decomposition.  The  six 
main  subproblems  have  been  generalized  into  the  following 
groups : 

1)  Multi-programming  support  functions 

2)  ProCess  management  functions 

3)  Resource  and  memory  management  functions 

4)  Supervisor  process  functions 

5)  Device  management  functions 

6)  Message  facility 

The  requirements  statement  are  decomposed  into  these  six 
main  subproblems  and  are  presented  in  Appendix  F. 


The  following  discussion,  will  highlight  the  character¬ 
istics  and  discrepancies  discovered  in  each  main;  subproblem. 
6.2. 1  MULTIr-PROGRAMMING  SUPPORT  FUNCTIONS : 

The  requirements  which, decomposed  into  the.  multi¬ 
programming  support  main  subproblems  were  all  concerned;  with 
the  features,  and  facilities  that  must  be  provided  by  the 
operating  system  in  a  multi-programming  environment.  These 
features  include! 

.  a  multi-programming  environment,  .must  exist 
.  job  scheduling 
.  re-entrant  and  pure  code 
..  supervisor  process  support 
synchronization  techniques 
..  protection  among  jobs 

The  seed  node  was  requirement  5,  "The  operating  system  must 
provide  for  a  multi-programming  environment” . 

However ,  it  must  be  noted  that  requirement  43,  "P-V 
mechanisms  must  be  provided",  had  a  larger  number  of  links 
than  requirement  5,  The  P-V  mechanism  provides  the  basic 
multi-programming  support  by  synchronizing  operating  system 
functions,  but  it  represents  a  specific  tool  rather  than  a 
focus  for  the  main  subproblems.  In  addition ,  the  P-V 
mechanism  is  used  for  four  distinct  functions.  Therefore , 
it  was  decided  to  further  investigate  this  requirement  and 
attempt  to  .redefine  it; 

Some  of  the  requirements  have  a  dual  function,  and. 


therefore ,-  decomposed  into  this  MS;,  which  at  first’  appeared 
counter-intuitive  ?  for  instance,  the  requirement,  "Device 
handler  routines  must  support  multiple  job.  streams’  from 
card  readers",  Intuitively,  one  would  have  expected  this 
requirement  to  fall  squarely  in:  the  device  management  MS'. 
However,  the.  issue  is  the  requirement  to,  support  multi¬ 
programming  by  providing  input  from  multiple  job  streams. 

It  is  expected  that  such  dual  requirements  will  also  have 
interfaces  linkages  between  the  two  MS  in  which  they  .seem 
to  belong.  This  will  be  investigated  later. 

*  This  MS  did  not  decompose  upon  the  second  decomposition. 
6.2.2  PROCESS  MANAGEMENT: 

The  smallest  computation  entity  defined  by  the  operating 
system  is  the  process;  therefore,  the  operating  system  must 
recognize  this  feature  and  provide  the  necessary  functions 
for  support  of  the  process.  The  requirements  which  decom¬ 
posed  into  this  MS  constitute  the  largest  set  of  requirements 
in  a  given  MS  and  deal  with  those  basic  functions  required 
for  process  support.  These  features  include: 

.  Process  creation/destruction 
.  Allocation/De-allocation  of  a  processor  to  a 
process1 
.  Time- slicing 

i  Extended  machine  instruction  environment 
.  Process  Scheduling 

The  seed  node-  for  the  MS  was  requirement  6,  "The  operating 
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system  must  be  process  oriented" ,  which  is  indeed  the  focus 
of  the  MS. 

Requirement  44,  "An  interrupt  handler  must  be  provided" 
had  nearly  the  same  number  of  linkages  as  .requirement  6. 

Time  slicing  CPU  usage  requires  an  interrupt  handler? 
however,  this  is  not  the  only  function  of  the  interrupt 
handler.  This  requirement  presented  problems  later  in  the 
interface  analysis .  Therefore  ,  it  was  decided  to  redefine 
the.  requirement  by  separating  it  into  a  number  of  distinct 
interrupt  handlers. 

The  decomposition  included  one  counter-intuitive 
requirement . 

"Message  facility  must  be  accessible  to  all  processes." 
It  was  expected  that,  this  requirement  would,  decompose  in  the', 
message  facility  MS.  Upon  examination  of  the  interdepen¬ 
dency  assessment  and  the  conceptual  models  used  .for  this 
requirement,  it  was  noted  that  the  requirement  is  defined  as 
being  interrelated  with  three  requirements  in  the  MS  and 
only  one  in  the  message  facility  MS.  The  issue  there  is.  one 
of  process  accessibility  to  the  message  facility-  which  is- 
the  primary  means  for  interprocess,  communication.  Therefore, 
this  requirement  related  more  closely  to  process  support 
than  to  the  message  facility. 

This  main  subproblem  decomposed  into  three  subproblems 
in  the  second  decomposition. 


-  77  - 

6.2.3  RESOURCE  AND.  MEMORY  'MANAGEMENT  FUNCTIONS : 

This  main  subproblem  is  composed  of  requirements  which 
deal  with  resource-  allocation;  in  general,  and'  memory 
management  in  particular.  The  functions  concerning  resource 
allocated  include : 

.  Resources  are  requested  through  the  supervisor. 

.  Information  tables  are  utilized  to  monitor  resource 
allocation, 

.  Operating  system  can  dynamically  allocate  memory  for 
its  own  use. 

The  requirements  dealing  with  memory  management  functions 
include ; 

.  Operating  system  must  allocate  memory. 

.  The  mechanisms  by  which  memory  is  allocated, 
protected;  and  reclaimed. 

This  main  subproblem  essentially  has  three  nodes  of  similar 
linkage  value.  The  three  requirements  all  deal  in  general 
terms  with  resource  and  memory  allocation,  but  no  clear 
definition  is  apparent;  It  can  be  argued  that  memory 
management  is  a  subset  of  the  general  resource  management 
function  of  the.  operating  system,  it  is  noted  that  this  MS 
has  the  largest  number  of  interfacing  linkages  with  other 
main  subproblems.  This  was  expected  since  the  members  of 
the  MS  seem  to  cover  such  a  broad  area  of  responsibility. 

This  requirement  decomposed  into  two  subproblems  in  the 


second  decomposition.. 


6.2.4  SUPERVISOR;  PROCESS:. 

The  requirements  which  decomposed  into  this  main  sub- 
problem  all  deal  with  the  functions  of  the  supervisor 
process.  The  supervisor  process  is  that  process  which 
schedules  jobs  and  prepares  them  for  execution.  Many  of  the 
functions  normally  performed  by  the  supervisor  were 
decomposed  into  the  multi-programming  support  main-  sub¬ 
problems,  particularly  the  job  scheduling  function..  The 
supervisor  process  is  a  subset  of  the  functions  required  for 
multi-programming  suppprt  and ,  therefore ,  this  result  seems 
to  make  sense.  It  is  also  noted  that  there  are  a  large 
number  of  linkages  between  the  supervisor  process  main 
Subproblem'  and  the  multi-programming  support  module . 

>  The  existence  of  a  supervisor  process  module,  distinct 
from  the  multi-programming  support  module  is  considered  a 
significant  insight  into  the  problem  structure.  The  design 
problem  structure  dictates  that  both  the  supervisor  process 
and  multi-programming  support  main  subproblems  are  dis¬ 
tinctly  separate  at  the  same  level  of  comparison  and 
deserve  equal  design  concern* 

This  module  did  not  decompose  on  the  second  decompo¬ 
sition. 

6.2.5  DEVICE  MANAGEMENT  -FUNCTIONS : 

The  members  of  this  module  clearly  are  concerned  with 
the  functions  required  for  device  management.  These 
functions  include: 
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.  A-  device  management  routine . 

.  Devices  and  protocols  required  to  support  multi¬ 
programmings. 

The  seed  node  for  this  main  subproblem  was  requirement  36. 
"The  operating  system  must  supply  a  device  management 
routine."  This. main  subproblem  decomposed  very  clearly; 
that  is-,  it  had  the.  highest  strength,  value  for  all  the  main 
subproblems  which  aid  not  decompose  on  the  second 
decomposition. 

6.2,6  MESSAGE  FACILITY: 

All  of  the  requirements  in  the  module  directly  address 
the  needs  for  amessage  facility/  which  is  an  interprocess 
communication  technique  in  the  Sample  Operating  System 
which  enables  user  processes  to  communicate  and  synchronize 
execution. 

The  seed  node  for  this  main  subproblem  was  requirement 
46.  "A  message  facility  has  many  requirements  since  there 
are  many  features  defined  for  use  of  the  facility." 

Although  the  message  facility  may  seem  to  be  a  relatively 
less  important  function  of  the  operating  system,  the  decom¬ 
position  methodology  implies  that  it  constitutes  a  complete- 
main  subproblem.  It  may  be  that  one  may  generate  an  entire 
main  subproblem  just  by  defining  a  large  number  of  require¬ 
ments  for  a  relatively  insignificant  feature;  or  conversely., 
this  facility  may  be  of  greater  significance  to  the  operating 
system  than  previously  anticipated. 


This  module  did,  not  decompose  in  the  second  decompo¬ 
sition  i 


A  second  decomposition  was  conducted  as  described  in 
section  6.1  and  resulted  in  the  decomposition  of  MS  2  and 
MS  3  into  three  and  two  subproblems  respectively.  The 
terra  subproblem  will  be  used  to  describe  the  clusters  which 
resulted  from  a  second  decomposition  of  the  main  subproblem. 
6.3.1  MS  2  -  PROCESS  MANAGEMENT  FUNCTIONS:: 

MS.  2  decomposed  into  three  subproblems  as  follows: 

1)  MS  2A  r-  Subproblem  A:  Process  Creation  and 
Scheduling 

This  subproblem  is  designated  MS  2A.  All  of 
the  requirements  in  the  subproblem  were  -concerned 
with  process  creation  and  scheduling .  These 
functions  included  such  features  as  initial  process 
creation/  process  identification/  process  blockage, 
scheduling,  and  message  facility  accessibility. 

2)  MS  2B  -  Subproblem  B:  Process/Operating  System 
Interface 

This  subproblem  is  designated  as  MS  2B.  All 
of  the  requirements  in  this, subproblem  were  concerned 
with  the  extended  machine  instructions  which  are  the 
means  by  which  processes  communicate  with  the 
operating  system. 
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3)  MS  2C  -  Subproblem  C:  Process  Time-Slicing 

This  subproblem  is  designated  MS  2C,  All  of 
the,  requirements  in  this  .subproblem  are  concerned 
with  process  time-slicing,  the  process  scheduler's 
role  and  the  interrupt  mechanism  required  to  handle 
timer  interrupts.  As  pointed  out  previously,,  the 
interrupt  handler  includes  many  more  functions  than 
time  interrupts.  This  caused  some  problems  in 
interfaces  descovered  in  the  later  stages;  there¬ 
fore,.  it  was  decided  to  redefine  this  requirement 
to  explicitly  define  all  of  its  functions. 

6.3,2  MS  3  RESOURCE  AND  MEMORY  MANAGEMENT  FUNCTIONS: 

MS  3  decomposed  into  two  subproblems  as  follows: 

1).  MS  3A  -  Subproblem  A:  Resource  Allocation 

This  subproblem  is  designated  as  MS  3A.  This 
subproblem  was  concerned  with  the  allocation  of 
resources  in  general,  and  the  mechanism  for  memory 
allocation  in  particular.  As  before,  this  sub¬ 
problem  is  not  clearly  defined  since  it  concerns 
both  issues.  First,  the  subproblem  deals  with  some 
broad  issues  of  how  resources  are  allocated,  to 
whom  and  When  are  they  allocated.  Second,  the 
subproblem  deals  with  the  protocols  for  memory 
allocation  and  de-allocation;  specifically,  only 
the  operating  system  may  dynamically  allocate 
memory.  It  was  decided  to  further  investigage  the 


issues  of  resource  .allocation-  and  memory  allocation' 
in  the  next  iteration  to  determine  if  the  require¬ 
ments  or  the  conceptual  models  were  ill -defined  or 
improperly  assessed. 

2)  MS  3B  -  Subproblem  B:  Protection 

This  subproblem  was  designated  MS  3B.  This 
subproblem  is  concerned  with  the  protection  mech¬ 
anisms  for  both  memory  and  user  processes. 


6. 4  Relationships  Among  the  Main  Subproblems 

The  relationships  among  the  main  subproblems  are  best 
explained  by  examining  the  focus  of  each  main  subproblem 
and  the  conceptual  models  used  in  the  interdependency 
assessment  phase  which  motivated  the  linkages.  The  software 
package  makes  the  linkages  explicit  through  the  "PRLK" 
command  the  results  are  presented  in  Appendix  E. 

The  linkage  between  main  subproblems  were  generalized 
into  interfaces  between  the  main  subproblems.  The 
following  discussion  will  note  the  general  characteristics 
of  these  relationships. 

6.4.1  LINKAGES  BETWEEN  MS  1  MULTI-PROGRAMMING  AND  MS  2 
PROCESS  MANAGEMENT  FUNCTIONS: 

1)  MS  1  Multi-programming  Support; 

MS  2A  Process  Creation/Scheduling: 

This  interface  between  these  two  subproblems 
consisted  of  the  mechanisms  for  providing  multi- 
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programming  ;by  process,  creation,  blockage,  and 
synchronization .  Processes;  are  created  by  the 
system  and'  scheduled'  in  a  round-robin  fashion  to 
achieve  multi-programming  of  user's  jobs. 

2)  MS  1  Multi-programming  Support; 

MS  2B  Process/Operating  System  Interface: 

This  interface  between  these  two  subproblems 
was  concerned  with  signaling  processing  completion 
<to  the  operating  system,  so  that  the  next  process 
could  begin . 

3)  MS  1  Multi-programming  Support; 

MS  2C  Process  Time-Slicing: 

The  interface  between  these  two  subproblems 
was  concerned  with  the  mechanism  of  time-slicing 
CPU  usage  to  achieve  muiti -programming .  The 
interrupt  handler  requirement  was  included  in  this 
interface;  when  it  seemed  to  belong  more  properly 
in  the  MS  2B  subproblem.  This  problem  supported 
the  need  to  re-examine  the  interrupt  handler 
requirement . 

6.4.2  MS  1  MULTI-PROGRAMMING  -  MS  3  MEMORY  MANAGEMENT 
FUNCTIONS : 

1)  MS  1  Multi-programming  -  MS  3A  Resource  and 
Memory  Allocation 

The,  interface  between  these  two  subproblems* 


was  concerned  with  the  mechanisms  for  user  and 


system  allocation  of  memory.  Dynamic  allocation  of 
memory  is  restricted  to  the,  system  processes . 

,  2 ).  MS  1,  Multi-programming  -  MS  3B  Protection . 

The  interface  between  these  two  subproblems 
was  concerned  with  protection  of  user  jobs  and 
memory.  The  interface  did  not  deal  with  the 
mechanisms  of  protection,  but  the  fact  that  pro¬ 
tection  mechanisms  must  exist  to  support  multi¬ 
programming. 

6.4.3  MS,  1  MULTI-PROGRAMMING  -  MS  4  SUPERVISOR  PROCESS: 

The  interface  between  these  two  subproblems  was 

concerned  with  the  mechanisms  for  the  protection  of  user 
jobs  and:  system  processes.  Protection  here  is  defined  at 
the  job  level  controlled  by  th&  supervisor.. 

6.4.4  MS  1  MULTI-PROGRAMMING  SUPPORT  -  MS  6  DEVICE 
MANAGEMENT: 

The  interface  between  these  two  subproblems  is  con¬ 
cerned  with  the  procedural  mechanisms  by  which  devices 
support  multi-programming;  especially  the  existence  of  a 
device  handler  routine  and  the  dedication  of  devices  to.  user 
jobs. 

6.4.5  MS  2  ’PROCESS  MANAGEMENT  -  MS  3  MEMORY  MANAGEMENT 
FUNCTIONS: 

1)  MS  2A  Process  Creation  and  Scheduling; 

-MS  3A  Resource  Allocation: 

The  interface  between  these  two  subprobiems 


was  concerned  with  'the  use  of  information  tables 
to  enable  the  operating  system  to  monitor  processes 
and.  resources.  This  interface  explicitly  points 
out  that  since  processes  and  resources  must  be 

monitored,,  the  operating  system  should;  attempt,  to 

* 

use:  the  same  mechanism  to  accomplish  this  task. 

2)  MS  2A  Process  Creation  and  Scheduling? 

MS  3B  Protection: 

The  interface  between  the  subproblems  is 
concerned  with  identification  of  processes  by 
symbolic  name  for  protection  purposes. 

3) .  MS  2B  Process/Operating  System  Interface;, 

MS  3A  Resource  Allocation: 

The  interface  between  these  two  subproblems 
was  concerned  with  freeing  memory  upon  completion 
of  a  job. 

4)  MS  2B  Process/Operating  System  Interface; 

MS  3B  Protection: 

The  interface  between  these  two  subproblems 
was  concerned  with  the  two  state  machine  concept. 

A  process  is  required  to  run  in  the  problem  state, 
all  resource  requests  must  pass  through  a  super¬ 
visor.  Therefore,  protection  is  afforded  by 
limiting  the  scope  of  system  functions  available 
to  the  user. 


5)  MS  2C  Process  Timer-Slicing;  MS,  3B  Protection: 

The  interface  between  these  two  subproblems  is 
concerned'  with  an  interrupt  handler  to  deal  with 
unauthorized  memory  access  requests.  This  inter- 
'  face*  seemes  distinctly  out  of  place,  until  one 
recalls  that  the  requirement  for  all  interrupt 
handlers  regardless  of  purpose,  is  located  in  MS  2C. 
The  lack  of  definition  of  the  interrupt  handier 
has  been  a  persistent  problem;:  therefore,  it  was 
redefined. 

6.4.6  MS  2  PROCESS  MANAGEMENT  -  MS  4.  SUPERVISOR  PROCESS: 

1)  MS  2A  Process  Creation/Scheduling; 

MS  4  Supervisor  Process: 

The  interface  between  these  two  subproblems 
was  concerned  with  the  protocols  for  user  process 
creation.  The  supervisor  .process  creates  one 
process  per  user,  initially;  all  others  are 
dynamically  created  by  the  user. 

2)  MS  2B  Proces s/Operating  System  Interface; 

MS  4  Supervisor  Process: 

The  interface  between  these  two  subproblems 
is  concerned  with  the  generation  of  an  end-of-job 
signal  from  the  final  .user  process  to  the  super¬ 
visor. 

3)  MS  2C  Process  Tim-Slicing;  MS  4  Supervisor  Process: 

The  interface  between  these  two  subproblems 


is  concerned  with,  the  interrupt  handler  which 
terminates  user  processing.  Again./  this  is  the 
same  persistent  problem  of  a  poor  interrupt  handler 
requirement/  since,  time-runout  is  just  one  of  the 
interrupts  for.  which  a  handier  is  required. 

6.4.7  MS'  2  PROCESS  MANAGEMENT  -  MS  5  MESSAGE  FACILITY: 

1)  MS  2A  Process  Creation  and  Scheduling? 

MS  5  .Message  Facility,: 

The  interface  between  these  two  subproblems  is 
Concerned  with  the  usage  of  a  message  facility  by 
user  processes  as  a  synchronization  technique. 

This  enables  user  processes  to  synchronize 
processing  by  starting  and  blocking  each  other 
using  messages. 

j  *■' 

2)  MS  2B  Process/Operating  System  Interface? 

MS  5  Message  Facility: 

The  interface  between  these  two  subproblems 
was  concerned  with  the  mechanisms  for  message 
generation  by  the  user  processes. 

6.4.8  MS  2  PROCESS  MANAGEMENT  -  MS  6  DEVICE  MANAGEMENT: 

MS  2C  Process  Time-Slicing?,  MS  6  Device  Management 

The  interface  between  these  two  subproblems 
was  concerned  with  the  generation  of  an  I/O  inter¬ 
rupt.  Once  again,  this  seems  to  be.  misplaced 
since  the  process  time-slicing  function  is  in  no 
way  concerned  with  I/O  interrupt  handling. 
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6.4'.  9  MS  3  MEMORY  MANAGEMENT  FUNCTIONS  -  MS  4  SUPERVISOR 
PROCESS  :■ 

1)  MS)  3A  Resource  Allocation;  MS'  4  Supervisor  Process 

The  interface  between  these  two  requirements- 
deals  with  the  issue  of  the  timing  of  resource 
allocation  and  de-allocation .  The  supervisor 
process  coordinates  all  resource  allocation  and 
de-allocation  for  the  operating  system.7 

2) :  MS  ,3B  Protection;  MS.  4  Supervisor.; 

This  interface  is  concerned:  with  establishing 
protocols  for  the  user  destruction  of  user 
processes  only.  The  supervisor  sets  up  a  memory 
partition  and  user1  processes  are  restricted  to 
that  memory  area;  therefore,  they  may  create  and 
destroy  processes  only  within  that  memory  area. 

6*4*10,  MS  3  MEMORY  MANAGEMENT  -  MS  5  MESSAGE  FACILITY: 

MS  3A  Resource  Allocation;  MS  5  Message  Facility: 

The  interface  between  these  two  processes  is 
concerned  with  the  queuing  requirements  for  the 
message  facility.  In  order  for  the  message 
facility  to  enqueue  itself,  it  must  be  able  to 
dynamically  allocate  a  buffer  area. 

6.4.11  MS.  3  MEMORY  ALLOCATION  -  MS  6  DEVICE  MANAGEMENT: 

MS.  3A  Resource  Allocation;  MS  6  Device  Management: 

The  interface  between  these  two  subproblems 
is  concerned  with  the  use  of  job  control  language 
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statements,  and  information  tables  to  specify  and 
'monitor  .resource  allocations. 

6.4.12  MS  4  SUPERVISOR  PROCESS  -  MS  6  DEVICE  MANAGEMENT.: 

The  interface  between  these  two  subproblems  is 
concerned  with  the  reclamation  of  device  resources  upon 
completion  of  a  job.  It  is  interesting  to  note  that  alloca¬ 
tion  is  not  an  issue,  because  that  is  controlled  in  MS  3 
Resource  and.  Memory  Allocation. 

6.5  Summary 

The  analysis  of  interfaces  between  subproblems  is  a 
verification  procedure  which  supports  the  initial  main  sub- 
problem  analysis.  Given  two  subproblems,  the  nature  of  the 
interface  couid’ be  intuitively  derived  based  on  one's 
knowledge  of  the  way  in  which  various  functions  of  the  oper¬ 
ating  system  are  supposed  to  interface.  An  examination  of 
the  links,  which  the  decomposition  methodology  has  implied, 
verifies  the  expected  result.  In  cases  where  the  expected 
result  was  not  verified,  or  if  counter-intuitive  interfaces 
were  implied,  one  could  go  back  to  the  main  subproblem  and 
find  misplaced  or  ill-defined  requirements.  The  second 
iteration,  of  the  decomposition  methodology  focused  on  a  re¬ 
definition  of  problem  requirements  and  a  re-assessment  of 
interdependencies  for  the  entire  requirements  set. 


CHAPTER  VII 

SECOND  ITERATION-  OF  TEE  DESIGN  PROBLEM 

The  entire  process  of  requirements  definition  and  inter¬ 
dependency  assessment  is  very  much  a  learning  process.  As 
one  continues  to  iterate  upon  the  process,  the,  requirements 
become  more  well-defined,  and  the  assessment  of  interdepen¬ 
dencies  more  consistent  through  the  application-  of  better 
conceptual  models .  The  second  iteration  is  a  cumulation  of 
a  series  of  smaller  iterations  and  reflects  a  flattening  of 
the  learning  curve. 

The  analysis  of  the  first  iteration:  of  the  design 
problem  highlighted  a  number  of  discrepancies  in  the 
resulting  decomposition.  The  requirements  which  were 
identified  as  being  problematic  were  re-examined  from  the 
perspective  of  their  role  in  the  Sample  Operating  System. 

Where  warranted,  these  requirements  were  re-defined.  At 

« 

this  point,  the  entire  requirements  set  was  reviewed  by  two 
graduate  students  familiar  with  operating  systems  in 
general;  namely,  Sid  Huff  and  Chat-Yu  Lariw  Based  on  their 
analysis  and  recommendations,  certain  requirements  were 
re-defined  or  re-written.  The  entire  requirements  set,  in 
its  final  form  as  contained  in  Appendix  G,  was  subjected  to 
the  interdependency  assessment  process.  This  chapter  will 
point  out  the  changes  made  to  the  requirements  set,  and 
present  an  analysis  and  discussion  of  the  resulting  problem 
structure.  The  chapter  is  organized  as  follows; 
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...  Requirements  re-definition. 

,.  An  analysis  of  the  resulting  problem  structure  for 
■the  second  iteration. 

Discussion  of  the  main  subproblems . 

.  Discussion  of  the  subproblems  generated  by  a  second 
decomposition . 

.  Relationships  among  the  main  subproblems. 

.  Comparison  of  the  first  and  second  interations . 

7.1  Requirements  Definition 

The  following  changes  were  made  to  the  preliminary  set 
of  requirements,  Appeindix  C,  based  on,  the  results  of  analysis 
of  the  first  iteration  and  examination  by  an  interested  third 
party. 

7.1.1  PRELIMINARY  REQUIREMENT  6: 

"The  operating  system  must  be  process  oriented."  This 
requirement  was  considered  to  violate  the  guideline  that  all 
requirements  be  defined  at  the  same  level  of  scope..  This 
requirement  defines  in  very  general  terms:  that  there  are 
certain  basic  functions  that  the  operating  system  must 
provide  at.  a  process  level.  The  implications  of  this 
requirement  have  been  made  explicit  in  other  requirements 
which  are  defined  at  a  level  more  consistent  with  the  remain¬ 
ing  requirements  set.  Therefore,  the  requirement  was  changed 
to  a  design  philosophy  and  appears  as  requirement  3  in  the 
final  requirements  set. 
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7.1.2  FINAL  ’REQUIREMENT  6: 

"Input/output  devices  are  limited  to  card  readers  for 
input  job  streams  and  line  printers  for  output. "  I/O 
devices  were  limited  by  the  designers  of  the  Sample  Operating 
System  to  card  readers  and  printers.  This,  was  not  made 
explicit  in  the  preliminary  requirements  set  and,  therefore, 
is  included  in  the  final  requirements  set  as  a  design 
constraint.. 

7.1.3  PRELIMINARY  REQUIREMENT  11: 

"User  communication  with  the  operating  system  is  via 
SVC  instruction.”  This  requirement  was  considered  to  violate 
the  implementation  independence  guideline  for  requirement 
definition.  The.  specification  of  "SVC  instruction”  con¬ 
strains  the  viewpoint  of  the  designer  unnecessarily. 

Therefore,  the  requirement  was  re-written  and  appears  as 
requirement  12  in  the  final  set:  "User  communication  with 
the  operating  system  is  via  special  call”. 

7.1.4  PRELIMINARY  REQUIREMENT  13: 

"The  supervisor  process  must  create  and  delete  the 
environment  in  which  a  job  runs."  This  requirement  was 
awkward  ahd  unclear.  Therefore,  it  was  re-written  as 
requirement  19  in  the  final  set:  "The  supervisor  process 
must  schedule  jobs  and  prepare  the  job  for  execution”. 

7.1.5  PRELIMINARY  REQUIREMENT  24: 

"A  process  shall  be  blocked,  and  control  released  to 
the  traffic  controller,  when  a  timer  runout  trap  is  detected." 
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This  requirement  states-  that  there  is  a.  time  limit 
established  for  processes;  yet,  it  does  not  explicitly  state 
the  time  limit.  Therefore,,  the  requirement  was  re-written 
.making  the  time  limit  explicit,  and  is  presented  as 
requirement  25  of  the  final  set:  "A  process  must  be  blocked 
and  control  released  to  the  process  scheduler  when  a. time 
quantum  of  50  ms  is  exceeded". 

7.1.6  PRELIMINARY  REQUIREMENT  23: 

"The  supervisor  process  must  reclaim  all  system 
resources,  when  an  error  condition  abnormally  terminates  a 
job."  This  requirement  was  unclear,  since  a  user  process  is 
created  for.  each  job.  Also  the  user  may  create  additional, 
processes,  any  one  of  which  may  create  an  error  which 
terminates  an  entire  job.  Therefore,  the  requirement  was 
re-defined  and  is  presented  as  requirement  29  in  the  final 
set:  "The  supervisor  process  must  reclaim  all  system 
resources  when  an  error  condition  is  raised  by  a  process". 
7.1; 7  PRELIMINARY  REQUIREMENT  41: 

"Input/output  devices  operate  .via  multiplexor  channel." 
This  requirement  violates  the  implementation  independence 
guideline  for  requirement  definition,  and  is  in  fact 
redundant  in  the  case  where  device**  are  dedicated.  The 
requirement  was,  therefore,  eliminated; 

7.1.8  PRELIMINARY  REQUIREMENT  43  :, 

"The  name  of  the  sending  process  must  be  prefixed  to  a 
message.  "-  This  requirement  violated  the.-  implementation 


independence  guideline  for  requirement  definition,  sin/oe  the 


real  issue  is  the  fact  that  the  receiving,  process  must  be 
able  to  determine  which  process  sent  the  message.  Therefore, 
the  requirement  Was.  re-written  and  is  presented  as  require- 
inent.  53  in.  the  final  set.:  "The  process  receiving  a  message 
must  be  able  to  determine  the  originator  of  the  message". 
7.1.9  PRELIMINARY  REQUIREMENT  43: 

"A  process  synchronization- mechanism  must  be  provided." 
7!his  requirement  was  the  source  of  a  number  of  inconsisten¬ 
cies  in  the  first  iteration  of  the  assign  problem.  Upon 
closer  examination,  it  was  determined  that  the  process 
synchronization  mechanism  has  a  number  of  specific  uses. 

The  requirement  was  re-defined  to  clarify  the  use  of  the 
process  synchronization  mechanism  and  hopefully,  reduce  the 
inconsistencies  in  the  design  problem.  The  requirement  was 
re-defined  as  follows: 

Final  Requirement  43 

"A  process  Synchronization  mechanism  must  be  provided 

to  serve  as  a.  lock  on  a  database . " 

Final  Requirement  44 

"A  process  synchronization  mechanism  must  be  provided 

for  the  timing  of  synchronization  processes." 

Final  Requirement  45 

"A  process  synchronization  mec  anism  mu at  be  provided 


for  synchronization  between  the  send  and  receiver  in 
message  processing." 
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Final  Requirement  4 6 

"A  process  synchronization  mechanism  must  be  provided 
to  lock  a  device." 

7.1.10  PRELIMINARY  REQUIREMENT  44: 

"An  interrupt  mechanism  must  be  .provided,  "'  This 
requirement  was  identified  as  being  poorly  defined  and 
leading  to  inconsistencies  in  the  first  iteration  of  the 
design  problem.  An  interrupt  handler-1  ,is  provided  by  the 
operating  system'  for  a  number  of  specific  interrupt, 
mechanisms i  Therefore,  this  requirement  was  re-defined  to 
explicitly  define  each  of  the  interrupt  handlers  as  follows: 
Final  Requirement  47 

"An  interrupt:  handler  routine  must  be  provided'  for  I/O 
interrupts . " 

Final  Requirement  48 

"An  interrupt  handler  routine  must  be  provided  for 
program  interrupts . " 

Final  Requirement  49 

"An  interrupt  handler  must  be  provided  for  supervisor 
call  interrupts . " 

Final  Requirement  50 

"An  interrupt  handler  must  be  provided  to  handle 
external  interrupts." 

7.1.11 

The  following  requirements  were  found  to  be  missing 
from  the  original  requirements  set  and,  therefore,  added: 
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Final  Requirement  7.1 

"The  I/O  interrupt  .handler  routine  must  provide  for 
a  synchronous  scheduling  of  a  process  requiring  fast 
processing. ” 

Final  Requirement  72 

"The  operating  system  must  include  a  task  which  loads 
the  0/S  into  the  computer  and  defines  the  processing 
environment . n 

These  changes  were  incorporated  into  the  final  requirements 
set,  and  -the  interdependencies  between  requirements  were 
assessed.  The  next  section  presents  an  analysis  of  the 
resulting  problem  structure  after  the  application,  of  the 
decomposition  methodology,* 

7.2  Analysis  of  the  Resulting  Problem  Structure  for  the 
Second  Iteration 

A  total  of  seventy-two  requirements  were  input  into  the 
software  analysis  package  for  decomposition.  Appendix  I 
contains  a  copy  of  the  output  of  the  decomposition  and  will 
be  referred  to  during  the  analysis.  As  before,  the  analysis 
proceeded  in  the  following  manner. 

First,  the  inpu.t  data  was  verified. 

Second,  all  isolated  nodes  were  identified.  In  this 
decomposition,  requirement  72,  "The  operating  system  must 
include  a  non-system-  resident  task  which  loads  the  O/S  into 
the  computer  and  defines  the  processing  environment"  was 


identified,  as  being  isolated.  Although  certainly  a 
consideration  for  design,  the  initial  program  load  routine 
is  tailored  to  the  final  operating  system  design.  The  IPL 
routine  may  call  routines  provided  by  the  operating  system, 
but  the  requirements  for  IPL  are  not  usually  considered  in 
the  design  of  the  operating  system.  As  before,  ail  padded 
nodes' were  deleted  at  the  time. 

The  adjacency  matrix  was  decomposed  according  to  the 
procedure  outlined  in  section  2 . 3  and  the  results ,  including, 
a  heirarchical  tree  are  presented  in  Appendix  I.  The  design 
requirements  decomposed  into  eight  clusters  or  main  sub- 
problems.  The  heirarchical  clustering  method  -3  was  used  to 
generate  the  evaluation  parameters.  The.  evaluation  para¬ 
meters  resulting  from  the  second  iteration  are  presented 
with  those  from  the  first  iteration  for  comparison: 


First 

Iteration 

Second 

Iteration 

Change 

Strength 

1.9864 

2.733 

27% 

increase 

Coupling 

.8674 

1.32 

34% 

increase 

Measure 

1.1119 

1.411 

20% 

increase 

Coupling/ 

Strength 

.43 

.48 

10% 

increase 

Average  Main 
Subproblem 

10.16 

8.125 

25% 

decrease 

Size 

An  examination  of  the  evaluation  parameters  indicates  that 
all  have  increased  from  the  first  to  second  iteration,  with 
the  coupling  parameter  showing  the  largest  increase. 


Note  also  that  the  strength  has.  increased  as  well  from 
the  first  to  the  second  iteration.  An  increase  in  strength, 
which  is  the  normalized  evaluation  of  subproblem  internal 
coherence ,  indicated  that  the  main  subproblems  which,  have 
been  identified  focus  closely  on  the  general  subject  of  each 
main  subproblem. 

Thus,  an  increase  in  the  strength  and  coupling  para¬ 
meters  has  resulted  in  an  increased  measure  for  the  "good¬ 
ness"  of  the  main  subproblem  decompositions.  This  measure 
is  strictly  relative  from  the  first  iteration  to  the  second 
'iteration.  The  real  value  of  the  second  iteration  lies  in 
the  increased  understanding  of  the  problem  structure  which 
is  generalized  by  the  decomposition  methodology. 

The  remaining  sections,  will  analyze  and  describe  the 
resulting  problem  structure.  The  final  section  of  the 
chapter  will  present  a  comparison  of  the  similarities  and 
•differences  of  the  -design  structure  implied  by  the  first 
;and  second  iterations. 

7'.  3 •  Main  Subproblems 

The  problem  structure  resulting  from  the  application  of 
the  de compos it ion  methodology  is  presented  in  Figure  7.1. 

The  problem  structure  was  interpreted  as  being  composed  of 
the  main  subproblems  depicted  as  blocks  in  Figure  7.1,  the 
subproblems,  generated  by  a  second  decomposition,  depicted 
as  circles  within  the  parent  main  subproblem.  The  inter- 


dependencies,  among  the  elements  of  different  subproblems 
were  generalized  into  interfaces  which  are  required  in  the 
design  process  between  subproblems. 

The  eight  main  subproblems  have  been  generalized  into 
the  following  groups : 

1)  Supervisor  Process. 

2)  Extended  Machine  Instruction  Mechanism. 

3)  Process  Control  Functions. 

4)  Process  Creation  Functions. 

5)  Interprocess  Communication. 

6)  Memory  Allocation  Functions. 

7)  Device ' Management  Functions. 

8)  Process  Synchronization  Function. 

The  requirement  statements  have  been  separated  into  these 
eight  main  subproblems  and  are  presented  in  Appendix  J. 

The  following  discussion  will  highlight  the  general  and 
specific  characteristics  of  the  design  structure  implied  by 
the  decomposition  methodology. 

7.3.1  SUPERVISOR  PROCESS : 

The  requirements  which  decomposed  into  the  supervisor 
process  main  subproblem  were  all  concerned  with  the  genera¬ 
tion  of  a  multi-programming  environment  through  the 
supervisor  process.  The  supervisor  process  is  that  process 
which  prepares  and  schedules  the  user  jobs  for  execution. 

The  supervisor  process  then  consists  of  a  number  of  specific 
tasks  which  must  be  performed  for  each  job  entering  the 
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system.  As  contained  in  main,  subprqbiem  1,  these  tasks- 
include,:: 

.  Resource  allocation::  system  resources  must  be  allo¬ 
cated  to  each  job  as  it.  enters  the  system.  These 
resources  consist  of  memory  and  devices. 

i  Job  scheduling :  the  supervisor  schedules  each  job 
for  execution.  This  system  uses  a  very  simplified 
algorithm  {first-come,  first-served). 

.  Loading:  the  supervisor  process  must  load  each  user 
job  into  a  specific  memory  area. 

.  Characteristics  of  the  supervisor  process:  the 
supervisor  process  must  be  modularized  and  all  system 
processes  are  written  in  re-entrant  and  shared  code. 
This  main  subproblem  had  the  lowest  individual  strength 
parameter  for  all  the  main  subproblems,  indicating  that  the 
requirements  are  not  exceptionally  cohesive;  or  conversely 
that  the  requirements  in  the  main  subproblem  cover  a  wider 
scope. 

The  main  subproblem  did  not  decompose  on  the  second 
decomposition. 

7.3.2  EXTENDED  MACHINE  INSTRUCTION  MECHANISM: 

The  requirements  in  this  main  subproblem  are  all 
concerned  with  the  extended  machine  instruction  mecnanism. 
The  description  of  the  Sample  Operating  System  in  section 

3.2  included  a  brief  explanation  of  the  purpose  of  the 
extended  machine  instructions.  Basically,  the  extended 
machine  instructions  were  provided  to  enable  the  user  to 
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perform  certain  resource  management  functions  and  hardware- 
like  instructions . 

This-  main  subproblem  contains  the-  requirements-  which 
deal  with  the.  characteristics  'and  protocols  for  the  use  of 
the  extended  machine  instructions. 

This  main  subproblem  did  not  decompose  on  the  second 
decomposition. 

7.3.3  MS  3  PROCESS  CONTROL  FUNCTIONS: 

The  requirements  in  the  subproblem  are  all  concerned 
with  -the  functions  necessary  to  control  processes  in  the 
operating  system.  Once  created,  a  process  may  be  "blocked" 
or  ready  to  run.  When  "ready  to  run”,  a  process  may  be 
"running"  or  "waiting".  This  main  subproblem  identifies  the 
states  of  blocked,  running,  or  waiting.  This  main  sub¬ 
problem  also  identifies  what  conditions  may  change  a  process 
state  and  how  resource  allocation  is  state-dependent. 

The  redefinition  of  the  interrupt  handler -requirement 
is  clearly  apparent  in  this  main  subproblem.  The  control  of 
processes  in  the  operating  system  is  interrupt-driven;  that 
is,  once  a  process  becomes  eligible  to  run,  its  execution 
is  dependent  upon  a  number  of  interrupts  which  are  generated 
in  response  to  an  asynchronous  or  ah  exceptional  event  in 
the  program.  This  main  subproblem  includes  all  of  the 
interrupt  handler  routines  and,  therefore,  provides  for  the 
control  of  processes. 

i 

The  main  subproblem  contained  two  requirements  which 


did  not  seem  to  fit  into  the  classification  of  process 
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control.  .They  are 
Requirement  23 

"Supervisor  routine  must  reclaim  all  system'  resources 
when  a  job  is  completed.-" 

Requirement  29 

"Supervisor  routine  must  reclaim  all  resources  when  an 
error  condition  is  raised." 

Theses  requirements  seem  to  belong  in  the',  supervisor  process 
main'  subproblem.  The  supervisor  process  is  initially 
created,  one  per  input  job  .stream.  It  performs  -its  func¬ 
tions  of  resource  allocation,,  scheduling,  and  loading  as  a 
separate  process.  After  all  this  has  been  done,  the  super¬ 
visor  process  is  no  longer  needed  until  the  user's  job  ends. 
It  stops  funning  and  waits  for  a  message,  "success"  or 
"failure",  signalling  completion  to  come  from  the  user's 
program. 

According  to  this  scheme,  the  supervisor  is  dependent 
upon  an  interrupt  signal  generated  by  the  user  for  successful 
completion,  or  by  the  system  in  the  way  of  an  error,  to 
restrict  and  reclaim  all  the  resources  of  the  current  user. 
Therefore,  the  mechanism  by  which  the  supervisor  process  is 
signalled  to  restart  is  contained  in  the  interrupt  handler. 
This  is  a  case  in  which  the  implementation  scheme  of  the 
interrupt  handler  and  supervisor  process  restart  ought  to  be 
considered  simultaneously.  When  viewed  from  this  perspec¬ 
tive,  it  makes  sense  that  requirements  23  and  29  were 
decomposed  into  main  subproblem  3. 


This-  main  subprOblem  decomposed  into  three  subproblems 
during  the-:  second  decomposition. 

7 .3;.  4  MS  4  PROCESS  CREATION: 

The  requirements  in  -this  main  subproblem  were  all 
concerned  with  the  protocols  for  process  creation .  Initially 
the  operating  system  creates  a  single  process  for  each  user's 
job.  The  user  may  then  create  additional  processes  dynami¬ 
cally  during  execution.  Naturally  the  system  imposes  certain 
constraints  and  procedures  upon  the  dynamic  creation  of 
processes.  These  constraints  and  procedures  are  the  focus 
of  this  main  subproblem  and  deal  with:. 

.  When  the  user  may  create  additional  processes? 

.  How  or  by  what  mechanises  may  these  processes  by 
created? 

.  How  are  user  processes  identified? 

.  What  restrictions  are  imposed  upon  dynamically 
created  processes? 

It  is  noted  that  dynamic  creation  of  user  processes  is  one 
of  the  main  functions  necessary  for  multi-programming  since 
the  processes  are  time-sliced  for  CPU  usage. 

This  main  subproblem  did  not  decompose  any  further. 

7.3.5  MS  5  INTERPROCESS  COMMUNICATION: 

The  requirements  in  this  main  subproblem  were  concerned 
with  the  tables  and  features  provided  by  the  operating 
system  for  interprocess  communication.  The  main  mechanism 
for  interprocess  communication  has  been  previously  identified 
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as  the  message  facility.  This  main  subproblem  contains  all 
the  requirements  for  the*  message  facility,  as  well  as  the 
requirements  for  system  tables,  required  to  monitor  and 
control  processing.  These  two  groups  of  requirements  have 
been  generalized  under  the  heading  of  interprocess  communi¬ 
cation  since  the  operating  system  communicates  internally 
with  information  tables  and  user  processes  communicate  via 
the  message  facility. 

This  main  subproblem  had  the  highest  strength  parameter 
of  all  main  subproblems,  indicating  that  this  main  sub¬ 
problem  had  the  greatest  internal  cohesiveness  among  require¬ 
ments-.  This  main  subproblem  decomposed  into  two  well- 
defined  subproblems  in  the  second  decomposition. 

7.3.6  MS  6  MEMORY  ALLOCATION  FUNCTIONS; 

The  requirements  in  this  main  subproblem  were  all 
concerned  with  the  protocols  for  memory  allocation  within 
the  Sample  Operating  System.  This  main  subproblem 
represents  a  distinct  change  from  the  first  iteration  in 
which  .numerous  resource  allocation  procedures  were  also 
contained  in  this  main  subproblem.  The  second  iteration  has 
resulted  in  a  veiy  well-defined  main  subproblem;  its 
strength  parameter  was  the  second  highest,  which  did  not 
decompose  upon  -the  second  decomposition. 

7.3.7  DEVICE  MANAGEMENT  FUNCTIONS: 

The  requirements  in  the  main  subproblem  were  all 
concerned  with  the  functions  required  for  device  management. 


This  main-  subproblem  was  virtually  unchanged  from  the 
previous  iteration.. 

The  main  subproblem  contains  the  requirements  which 
deal  with  the  .following  issues: 

The  existence  and  functions  of  a  device  management 
system. 

.  Procedures  for  requesting  resources  and  I/O  by  the 
user . 

This  main  subproblem-  did  not  decompose  upon  the  second 
decompos ition . 

7.3.8  PROCESS  SYNCHRONIZATION  FUNCTIONS: 

The  requirements  in  the  main  subproblem  are  specifi¬ 
cally  concerned  with  the  process  synchronization  mechanism 
provided  by  the  Sample  Operating  System.  This  main  sub¬ 
problem  resulted  from  the  redefinition  of  the  global  process 
synchronization'  requirement  contained  in  the  first  iteration 
of  the  decomposition  process.  The  requirements  were  re¬ 
defined  and  analyzed  independently  from  each  other.  The 
process  synchronization  mechanism  is  used  extensively 
throughout  the  Sample  Operating  System  to  provide  a  linked 
list  for  the  sequential  locking  of  resources. 

The  existence  of  a  main  subproblem  dealing  exclusively 
with  the  process  synchronization  mechanism  indicates  that 
the  implementation  of  this  mechanism  warrants  the  equiva¬ 
lent  amount  of  design  consideration  given  to  the  other  main 
subproblems . 
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This  main  subproblem  did  not  decompose  any  further. 


Generated  by.  a  Second  Decomposition 


A  second  decomposition  was  conducted  as  described  in 
section  7. 2,  and  resulted  in  the  decomposition  of  MS  3  and 
MS  5  into  three  and  two  subprobiems  respectively.  The 
following  discussion  will  describe  the  resulting  sub¬ 
problems. 

7.4.1  MS  3  PROCESS  CONTROL  FUNCTIONS: 

MS  3  decomposed  into  three  subproblems  as  follows: 

1)  MS  3A  Process  Scheduling: 

All  of  the  requirements  in  this  subproblem  were 
concerned  with  the  procedures  necessary  to  schedule, 
a  process* in  the  Sample  Operating  System.  This 
suhprohlem:  was;  .'similar  .to  'MS  -2A  '-p-rpoess-  -Creation- 
and  Scheduling,,  except;  that  the  functions  of 
.process  -creation:  have  now.  been  .separated  into  an 
entire  main  subproblem. 

2)  MS  33  System  Initiated  Interrupts': 

The  requirements  in  this,  subproblem  define  the 
types  of  interrupts  that  are  system  generated  to 
control  processing.  These  interrupts  are  centered 
around-  the  time-slicing  of.  CPU  usage  to  achieve 
multi-programming.  The  system  may  also  supply 
interrupt  handler  -routines  for  supervisor  calls 
and  for  external  interrupts. 


3)  MS:  3C  Process  initiated  Interrupts; 

in  contrast  to  MS  3B,  the  requirements  of  this 
•subproblem  are  concerned  with-  the  means  by  which  . 
user  processes  may  signal  the  operating  system  via 
interrupts  to  control  processing.  'The  user  process 
must  signal  completion  to-  the  operating  system  so 
that  resources  may  be  reclaimed-  and  other  processes 
scheduled;  Therefore,  the  subprbblem  is  primarily 
concerned"  with  user  signalling  completion  to  the 
operating  system.  As  previously  pointed  out:  in 
section  7.3.3,  this  subproblem  also  contains  the 
requirements  that  the  supervisor  process  be 
restricted  upon  completion  of  the  user's  job. 

7.4.2  MAIN  SUBPROBLEM  5;  INTERPROCESS  COMMUNICATION; 

MS  5  decomposed  into  two  subproblems  as  follows; 

1)  MS  5A  Operating  System  Information  Tables; 

The  requirements;  in  this  subproblem  a/e 
concerned  with  the  operating  system’s  use  of  infor¬ 
mation  tables  to  monitor  and  control  processing. 

The  requirements  deal  with  the  existence  of  such 
tables  and  the  fact  that  the  tables  must  be 
dynamically  allocated  and  released  by  the  operating 
system. 

2)  MS  5B  Message  Facility; 

The  requirements  of  this  subproblem  are 
concerned  with  the  existence  of  a  message  facility 
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•for  user  process  communication..  .The  message 
facility  is  the  primary  means  of  user  process 
communication,  and,  -like  information  tables,  must,  be 
a  dynamically  allocated  table  to  enable  queuing  of 
messages.  The  requirements  deal  with  the  pro¬ 
cedures  and  constraints  for  sending  and  receiving 
messages . 


7.5  Relationships  Among  the  Main  Subproblems 

The  relationships  among  the  main  subproblems  were 
investigated  as  previously  explained  in  section  6.4.  The 
linkages  between  main  subproblems  were  generalized  into  inter¬ 
faces  between  the  main  subproblems.  It  is  noted  that  the 
second  iteration  resulted  in  a  large  number  of  main  sub¬ 
problems  and  a  larger  coupling  parameter.  Therefore,  the 
number  of  linkages  between  main  subproblems  was  expected  to 
be  much  greater  than  in  the  first  iteration.  A  comparison 
was  made  of  those1  subproblems  actually  having  linkages  in 
the  first  air.d  second  iteration. 


First  Iteration  Second  Iteration 


Average  number  of 
linkages  between 
subprobl'ems  for 
which  linkages 
exist 

Number  of  existing 
linkages 


3.52  links 


subproblem 


2.52  links 
subproblem 


Although  the  number  of  subproblems  having  linkages  is 
greater  in  the  second  iteration  (36  vs.  27),  the  average 


number  of  linkages  between  subproblems  is  more  than  a  third 
les3.  This  indicates  that  the  interface  between  two  given 
subproblems  may  be  more  highly  defined  since  the  linkages? 
will  focus  on  a  fewer  number  of  issues..  The  following 
discussion  will  attempt  to  make  the  definition  of  interfaces 
between  subproblems-  more  explicit  . 

7.5.1  LINKAGES  BETWEEN  MS  1  SUPERVISOR  PROCESS  AND 
MS  2  EXTENDED- MACHINE  INSTRUCTION  MECHANISMS: 

The  interface  between  these  two  subproblems  is  formed 
due  to  the  use  of  a  special  call  instruction  to  request 
resources  from  the?  supervisor. 

7.5.2  MS  1  SUPERVISOR  PROCESS  AND  MS  3  PROCESS  CONTROL 
FUNCTIONS : 

MS  1  and  MS  3A,  Process  Scheduling: 

The  interfaces  between  these  two  subproblems  con¬ 
sists  of  conflicting  implementation.  First,  the  memory 
and  device  resources  are  allocated  on  a  job  level  by 
the  supervisor.  The  processor,  is  assigned  on  a  process 
level  only  when  a  process  is  runnable.  Second,  jobs 
are  scheduled  strictly  first-come,,  first-served,  but 
there  is  an  I/O  fast  processing-  scheme  that  enables 
asynchronous  scheduling  of  a  process  requiring  frequent 
update . 

MS  1  and  MS  3C  Process  Initiated  Interrupts: 

The  interface  between  these  two  subproblems  consists 
of  the  mechanism  by  which  the  supervisor  process  is  re- 


started  after  a  user  job:  terminates.  MS  3C  contained 
the  seemingly  misplaced  requirements  that  the  super¬ 
visor  must  reclaim  resources -when  a  job  terminates. 

This  interface  makes:  the  association  between  the 
supervisor  process  and  user  initiated  job  termination 
explicit,  and  verifies  the  decomposition  of  subproblem 
MS  3C  . 

7.5.3  MS  1  SUPERVISOR  PROCESS  AND  MS  4  PROCESS  CREATION 
FUNCTIONS : 

The  interface  between  these:  two  subproblems  consists  of 
the  protection  mechanisms  employed  by  the  supervisor  process 
to  insure  that  jobs  are  isolated  from  each  other.  The 
mechanism  is  the  creation  of  a  single  user  process  initially 
for  each  job,  which  runs  exclusively  in  the  user's  partition. 

7.5.4  MS  1  SUPERVISOR  PROCESS  AND  MS  5  INTERPROCESS 
COMMUNICATION: 

MS  1  and  MS  5A  Operating  System  Information  Tables 

This  interface  between  these  two  subproblems  deals 
with  the  i-act  that  the  supervisor  process  must  utilize 
information  tables  to  determine  what  resources  are  free  or 
in  use  to  support  multi-programming. 

7.5.5  MS  1  SUPERVISOR  PROCESS  AND  MS  6  MEMORY  ALLOCATION: 

The  interface  between  these  two  subproblems  obviously 

concerns  the  fact  that  memory  is  a  resource  which  must  be 
allocated  by  the  supervisor  process. 

7.5.6  MS  1  SUPERVISOR  PROCESS  AND  MS  7  DEVICE  MANAGEMENT: 
The  interface  between  these  two  subproblems  is  of  a 


dual  nature;.  First  the  device  handler  routine  directly 
supports  multi-programming  by  providing  multiple  job  streams 
from  multiple  sources  to1  the  system.  Second,  devices  are 
resources  which  must  be  allocated  to  jobs;  by  the  supervisor 
process. 

7.5.7  MS  1  SUPERVISOR  PROCESS  AND  MS  8  PROCESS 
SYNCHRONIZATION: 

The  interface  between  these  two  subproblems  is  formed 
when  the  supervisor  process  uses  process  synchronization 
m&chanism  as  a  lock  for  resource  allocation. 

7.5.8  MS  2  EXTENDED  INSTRUCTION  MECHANISM  AND  MS  3  PROCESS 
CONTROL  FUNCTIONS: 

■MS  2  and  MS  33  System  Initiated  Interrupts 

The  interface  between  these  two  subproblems  concerns 
the  fact  that  the  use  of  extended  machine  instructions 
generates  a  supervisor  call  interrupt.  A  handler, 
routine  must  be  provided  which  interprets  the  interrupt 
and  performs  the  intended  instruction. 

MS  2  and  MS  3C  Process  Initiated  Interrupts 

The  user  signals  process  completion  by  a  special 
extended  machine  instruction  which  is  the  interface 
between  these  two  subproblems. 

7.5.9  MS  2  EXTENDED  MACHINE  INSTRUCTION  MECHANISM  AND 
MS  4  PROCESS  CREATION  FUNCTIONS: 

The  processes  are  restricted  in  their  use  of  extended 
machine  instructions;  therefore,  this'  interface  is  concerned 


with  the  fact  that  dynamically  created  processes  run  in  the 
problem  state  while  extended  machine  instructions  are 
executed  in  the  supervisor  state. 

7.  5.10  MS  2  EXTENDED  MACHINE.  INSTRUCTION  MECHANISM  AND 
MS  5  INTERPROCESS  COMMUNICATION: 

MS  2  and  MS  5B  Message  Facility 

The  message  facility  is  available  to  all  processes 
via  extended  machine  instructions.  The  interface  is  con¬ 
cerned  with  the  use  of  extended  machine  instructions  in 
support  of  the  message  facility. 

7.5.11  MS  2  EXTENDED  MACHINE  INSTRUCTION  MECHANISM  AND 
MS  8  PROCESS  SYNCHRONIZATION: 

The  interface  between  these  two  subproblems  is  concerned 
with  the  protocols  for  use  of  the  process  synchronization 
mechanism.  The  synchronization  mechanism  is  available  via 
extended  machine  instruction;  but  since  it  serves  to  lock 
resources,  it  is  restricted  and  cannot  be  called  by  user 
processes. 

7.5.12  MS  3  PROCESS  CONTROL  FUNCTIONS: 

MS  3A  Process  Scheduling  and  MS  4  Process  Creation 
Functions 

The  interface  between  these  two  subproblems  is 
concerned  with  the  scheduling  of  dynamically  created 
user  processes.  Since  the  scheduling  is  strictly 
round-robin,  a  dynamically  created  process  is  scheduled 
upon  creation. 


MS  3A  and  MS  5  Interprocess  Communication/ 

MS  3A  and  MS  5A  Operating  System  Information  Tables 
The  interface  between  these  two  subproblems  is 
concerned  with  the  fact  that  ready  process  control 
blocks  may  be  chained  together  to  facilitate  round- 
robin  scheduling. 

MS  3A  and  MS  5B  Message  Facility 

The  interface  between  these  two  subproblems  is 
concerned  with  use  of  the  message  facility  as  a  means 
of  providing-  process  synchronization. 

MS  3A  and  MS  8  Process  Synchronization 

The  interface  between  these  two  subproblems  is 
concerned  with  the  use,  by  the  operating  system,  of 
the  process  synchronization  mechanism  to  schedule  or 
synchronize  its  own  system  processes. 

MS  3B  System  Initiated  Interrupts  and  MS  7  Device 
Management  Functions 

The  interface  between  these  subproblems  is  the  I/O 
interrupt  handler.  The  user  process  must  request  I/O 
through  the  operating  system  and  the  I/O  interrupt 
handler  is  provided  to  service  the  user's  request. 

MS  3C  Process  Initiated  Interrupts  and  MS  5B  Message 
Facility 

The  interface  between  these  two  subproblems  is 
concerned  with  the  fact  that  when  a  process  signals 
completion,  all  messages  waiting  to  be  read  by  that 
process  are  destroyed. 


MS  3C  arid  MS  6  Memory  Aii'ccatidn  Functioris 

Trie  interface  between  these  two  subproblems  is 
concerned  with  memory  reciaimation  once  the  user  job- 
has  completed. 

MS  3C  and.  MS  7  Device  Management  Functions 

The  interface  between  these  two  subproblems  is 
concerned  with  the  fact  that  the  device  handler  routine 
must  be  terminated  when  a  j,ob  is  terminated. 

MS  3C  and  MS  ‘8  Process  Synchronization 

The  interface  between  these  two  subproblems  is 
concerned  with  the  fact  that  all  locks  set  by  the 
operating  system  in  consideration  of  a  particular  job 
must  be  released  when  that  job  terminates. 

7.5.13  MS  4  PROCESS  CREATION  FUNCTIONS  AND  MS  5  INTER¬ 
PROCESS  COMMUNICATION  FUNCTIONS: 

MS  4  and  MS  5A  Operating  System  Information  Tables 
The  interface  between  these  two  subproblems  is 
concerned  with  protection  mechanisms  employed  by  the 
operating  system  to  protect  dynamically  created 
processes.  The  operating  system  utilizes  information 
stored  in  tables  to  protect  user  processes. 

MS  4  and  MS  5B  Message  Facility 

The  interface  between  these  two  subproblems  consists 
of  the  identification  of  user  processes  so  that  message 
originators  and  destinations  may  be  defined. 
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7.5.14  MS  V  INTERPROCESS'  COMMUNICATION  AND  MS  6  MEMORY 
ALLOCATION.: 

MS  5A  Operating.  System. Information  Tables  and  MS  6 
Memory  Allocation 

The  interface  between  these  two  subproblems  is 
concerned  with  the  use  of  information  tables  to  allo¬ 
cate  memory.  Memory  allocation  is  heavily  dependent 
upon  information  tables  to  identify  free,  areas  and  to 
enforce,  protection  rights  for  certain  memory  areas.. 

MS  5A  and  MS  7  Device  Management  Functions 

The  interface  between  these  two  subproblems  is 
concerned  with  device  management  functions  which  require 
dynamic  system  tables  to  monitor  and  control  the  allo¬ 
cation  of  device  resources. 

MS  5A  and  MS  8  Process  Synchronization 

The  interface  between  these  two  subproblems  is 
concerned  with  the  extensive  use  of  process  synchroni¬ 
zation  mechanism  with  a  semaphore  to  serve  as  a  lock 
on  a  database.  The  counting  semaphore  may  be  used  as 
a  prioritized  list  of  processes  waiting  for  a  particular 
resource. 

MS  5B  Message  Facility  and  MS  8  Process  Synchronization 
The  interface  between  these  two  subproblems  is 
concerned  with  the  use  of  the  process  synchronization 
mechanism  to  establish  an  ordered  queue  for  the  message 
facility. 
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7.5.16  MS'  6  MEMORY  ALLOCATION  FUNCTIONS  AND  MS  7  DEVICE' 
.MANAGEMENT': 

The  Interface  between  these  two  s.ubprobiems  is  con¬ 
cerned  ;with  the  use  of  job  control  language  statements  to 
specify  memory  resource  requirements.  The  JCL  statement 
requirement  is  decomposed  into  MS  7?  therefore-,  all.  resource 
requests  must  interface  .with  MS  7  to  specify  the  desired 
resources. 

7.5.17  MS  6  MEMORY  ALLOCATION  FUNCTIONS  AND  MS  8  PROCESS 
SYNCHRONIZATION: 

The  interface  between  these  two  subproblems  is 
concerned  with  the  use  of  the  process  synchronization 
mechanism  to  serve  as  a  lock  on  system  tables  to  prevent 
unauthorized  access  or  modification. 

7-.  5. 18  MS  7  DEVICE  MANAGEMENT  AND  MS  8  PROCESS 
SYCHRONIZATION  MECHANISM: 

The  interface  between  these  two  subproblems  is  concerned 
with  the  use  of  the  process  synchronization  mechanism  to  lock 
devices  in  the  device  management  function. 

7.5.19  SUMMARY: 

An  investigation  of  the  interfaces  between  pairs  of 
subproblems  identified  the  most  obvious  relationships  among; 
the  main  subproblems.  In,' one  case,  described  in  section 
7.5.2,  the  examination  of  interfaces  has  verified  a  seemingly 
misplaced  decomposition  of  requirements.  The  number  of 
interfaces  among  subproblems  has  decreased  significantly  in 
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the  second  iteration,  resulting  in  interfaces  which  are  more 
clearly  defined.' 

The1  final  section  of-  this  chapter  will  compare  the, 
problem  structures,  which  were  implied  by  the  first  and  second 
iterations  of  the  decomposition  methodology. 


7 .6  Comparison  of  the  Design  Structure  Implied  by  the  First 

and  Second  Iterations 

The  method  for  analyzing  the  similarities  and  differ¬ 
ences  in  the  design  structure  implied  by  the  first  and  second 
iterations  of  the  decomposition  methodology  was  to  compare 
the  subproblems  which  resulted  from  each  iteration.  Each 
iteration  was  analyzed  in  isolation  from  the  other;  there¬ 
fore,  the  title  of  each  subproblem  will  not  reveal  any  more 
than  a  general  similarity.  The  comparison  must  include  an 
analysis  of  the  functions  or  issues  involved  in  each  sub¬ 
problem  to  determine  how  the  nature  of  each  subproblem  has 
changed  from  the  first  iteration  to  the  second. 

The  first  -iteration  resulted  in  the  decomposition  of 
sixty-five  requirements  into  six  main  subproblems.  Two  of 
the  main  subproblems  decomposed  a  second  time  into  two  and 
three  subproblems.  Therefore,  the  first  iteration  resulted 
in  a  total  of  nine  distinct  subproblems  for  comparison.  The 
second  iteration  likewise  originally  resulted  in  a  decompo¬ 
sition  of  eight  main  subproblems,  again  two  of  which  further 
decomposed  into  two  and  three  subproblems.  Therefore,  the 
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second  iteration:  resulted  in  eleven  distinct  subproblems  for 


comparison5. 

7.6.1  -  GENERAL  FUNCTIONAL  'COMPARISON 


The  general  function-  of  each  subproblem  was  investigated 
from  the  first  iteration  and  compared  to  the  function  of  the 
subproblem  resulting  from  the  second  iteration.  A  .pair-wise 
subproblem  comparison  was  suggested  of  the  following  form: 


Subproblems  From 
First  Iteration 

1.  Supervisor  Process  1,. 

2.  Device  Management  2. 

Functions 

3.  Message  Facility  3. 

4.  Resource  and  Memory  4. 

Management 

5.  Process  Creation  and  5. 

Scheduling 

6.  Process/Operating  6. 

System  Interface 

7.  Process  Time-Slicing  7. 

8.  Multi-programming  8. 

Support  Functions 

9. 

10. 

11. 


Subproblems  From 
Second  Iteration 

Supervisor  Process 

Device  Management 
Functions 

Message  Facility 

Operating  System  Information 
Tables 

Memory  Allocation  Functions 
Process  Creation 

Process  Scheduling 

Extended  Machine  Instruc¬ 
tion  Mechanism 

System  Initiated  Interrupt 

Process  Synchronization 
Mechanism 

User  Initiated.  Interrupts 


7.6.2  COMPARISON  OF  SPECIFIC  SUBPROBLEM  FUNCTIONS: 

Supervisor  Process:  Both  iterations  identified  the  need 
for  a  supervisor  process,  which  prepares  and  schedules  jobs 


for  execution.  The  supervisor  process  in  the  second 
iteration  is-  more  well-defined  since  it  incorporates  many 
of  the  requirements  which  previously  had  been  decomposed 
into  the  multi-programming  support  subproblem.  The  require¬ 
ments  which  shifted  deal  specifically  with  the  functions  of 
the  supervisor  process  in  the  support  of  multi-programming. 

Device  management  functions:  The  subproblems  generated 
for  the  device  management  functions  were  nearly  identical 
for  the  first  and  second  iterations.  The  subproblem 
resulting  from  the  second  iteration  included  the  requirement 
for  job  control  language  statements.  In  the  previous 
iteration  this  requirement  had  been  contained  in  the  resource 
and  memory  allocation  function  subproblem. 

Message  facility  subproblems:  The  subproblems  generated 
for  the  message  facility  were  identical  from  the  first  to 
the  second  iteration.  However,  in  the  first  iteration  the 
message  facility  constituted  an  entire  main  subproblem; 
whereas  in  the  second  iteration;  it  was  a  subproblem 
generated  after  a  second  decomposition. 

Resource  and  memory  management  functions  and  operating 
system  information  tables  and  memory  allocation  functions:. 

‘The  first  iteration  of  the  design  requirements  generated 
a  main  subproblem  which  was  concerned  with  the  allocation  of 
resources  and  specifically  memory  by  the  operating  system. 
This  main  subproblem  was  better  defined  in  the  second 
iteration;  in  that  two  subproblems  were  generated  which 
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separated  the  functions  of  the  '(previous  main  subprobiem. 
Memory  .allocation  subproblem,,  in-  the  second  iteration,  is 
specifically  concerned  with  these  requirements  for  memory. 

The  operating  system:  information  tables  subproblem  deals 
with  the  protocols  and  information  requirements  which  had 
been  associated  with:  the  general  resource  management 
functions  of  the  first  iteration.  In  addition,  the  mechanics 
of  resource  allocation  were  decomposed  into  the  .supervisor 
process  subproblem  of  the  second  iteration  which  has  resulted 
in  more  well-defined  subproblems. 

Process  creation  and  scheduling  functions  and  process 
creation  and  process  scheduling  functions:  The  single  sub¬ 
problem,  Process  Creation  and  Scheduling  Functions,  of  the 
first  iteration,  was  decomposed  into  one  main  subproblem, 
Rrocess  Creation  and  one  subproblem,  Process  Scheduling 
Functions  in  the  second  iteration.  The  requirements 
involved,  in  both  iterations  are  identical.  The  functional 
separation  achieved  in  the  second  iteration  has  resulted  in 
more  clearly  defined  subproblems. 

Process/operating  system  interface  and  extended  machine 
instruction  mechanism:  The  requirements  contained  in  each 
of  these  two  subproblems  are  nearly  identical  from  the 
first  to  the  second  iteration.  However,  in  the  first 
iteration,  the  process/operating  system  interface  was  a  sub¬ 
problem;  whereas  in  the  second  iteration,  the  extended 
machine  instruction  mechanisms  constituted  an  entire  main 
subproblem. 
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Process  time-slicing  and  system  initiated- interrupts 
The  requirements  for  process  time-slicing  decomposed  in  the 
■first  iteration  into  a  single  subproblem-  entitled  "Process 
time-slicing".  In  the  second  iteration,  the  definition  of 
the  interrupt  handler  requirement  had  been  considerably 
expanded..  One  result  was  the  definition  of  a  subproblem 
dealing  with  system  initiated  interrupts .  The  main  focus  of 
system  initiated  interrupt  handler  was  with  time  runout 
however,  it  also  included  the  requirements  external  and  I/O 
interrupt  handler  routines  as  well. 

Multi-programming  support  functions  and  process  sychron- 
ization  mechanism:  The  multi-programming  support  function 
main  subproblem,  generated  in  the  first  iteration  was 
eliminated  in  the  second  iteration,  being  replaced  by  the 
process  synchronization,  mechanism  main  subproblem.  The 
multi-programming  support  functions  included  many  functions 
which  belong  to  the  supervisor  process.  In  fact,  it  was 
previously  argued  that  the  supervisor  process  main  subproblem 
couid  have  been  considered  a  subset  of  the  multi-programming 
main  subproblem.  In  the  second  iteration,  all  of  the 
requirements  representing  supervisor  process  functions  have 
been  decomposed  into  that  main  subproblem. 

The  process  synchronization  mechanism  requirement  was 
re-defined  from  the  first  to  the  second  iteration.  Since 
this  mechanism  provides  basic  multi -programming  support,  it 
had  decomposed  into  the  multi-programming  support  main  sub- 
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.problem  in  the  first  iteration.  After  the  redefinition  in 
the  second  iteration,  the  process  synchronization  mechanism 
had;  decomposed  into  a  distinct  and  separate  main  subproblem. 

User  initiated  interrupts:  The  redefinition  of  the 
interrupt  handler  routine  requirements  from  the  first  to 
the  second  iteration  resulted  in  the  decomposition  of  a  sub¬ 
problem  dealing  with  user  initiated  interrupt  handler.  Since 
the  main  focus  of  this  subproblem  involves  the  user  signaling 
completion  of  a  job,  it  had  no  similar  subproblem  counter¬ 
part  from  the  first  iteration. 

7.7  Summary 

The  comparison  of  the  problem  structure  implied  by  the 
first  and  second  iterations  yields  the  following  results: 

.  The  second  decomposition  resulted  in  a  greater  number 
of  subproblems. 

.  The  subproblems  resulting  from  the  second  decomposi¬ 
tion  were  more  weilrdefined  than  those  resulting  from 
the  first  iteration. 

.  The  changes  in  subproblems  from  the  first  iteration  to 
the  second  were  inituitive  and  seemed  to  result  in  a 
better  problem  structure. 

.  The  interfaces  between,  subproblems  in  the  second  iter¬ 
ation  were  also  more  clearly  defined. 

The  next  chapter  will  analyze  the  implications  of  the  second 
.iteration  problem  structure  on  the  design  of  the  Sample 

( 

Operating  System. 


CHAPTER  VIII 

IMPLICATIONS  OF  THE  DECOMPOSITION  PROCESS 
FOR  THE  DESIGN  OF  THE  SAMPLE  OPERATING  SYSTEM 

The  motivation  for  applying  the  decomposition  method¬ 
ology  was  to  generate  a  framework  upon  the  design  require¬ 
ments  of  the  Sample  Operating  System  to  -provide  insight  and 
understanding  of  the  relationships  among  the  system 
requirements.  The  framework  resulted  in  the  identification 
of  subprobleras  of  system  requirements  and  the  establishment 
of  relationships  between  pairs  of  subproblems.  The  frame¬ 
work  then  constitutes  a  better  basis  for  the  subsequent 
detailed  design  stage,  than  the  original  disjoint  set  of 
requirements.  Better  in  the  sense  that  a  design  team  now 
has  a  framework;  i.e.,  design  subproblems,  in  which 
alternative  implementation  schemes  may,  be  thoroughly 
investigated. 

The  prupose  of  this  chapter  is  to  examine  the  sub?? 
problems,  which  resulted  from  the  second  iteration  of  the 
decomposition  methodology,  from  the  perspective  of  the 
completed  Sample  Operating  System  to  determine  if  the- 
completed  design  is  verified  by  the  results  of  the  decompo¬ 
sition  methodology.  The  verification  procedure  was  first 
to  determine  if  the  Sample  Operating  System  was  designed  in 
a  manner  consistent  with  the  intuitive  results  of  the 
decomposition  methodology  by  a  comparison  of  the  specific 
functions  identified  for  the  heirarchically  structured  Sample 
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•Operating  System  with  the  functions  generalized  for  each 
subproblem  by  the  decomposition  methodology.  The  procedure 
attempted  to  determine  if  the  decomposition  methodology 
indeed  provided  a  framework  for  design;  yet  was  sufficiently 
unconstraining:  so  that  a  designer  was  free  to  investigate 
alternative  implementations  and  still  arrive  at  the  final 
Sample  Operating  System  design  as  it-  exists. 

Since  the  design  process  for  the  Sample  Operating 
System  is  not  documented  in  a  manner  that  would  elucidate 
the  decisions  made  'by  the  designers  in  the  early  stages  of 
the  design  process,  a  description  of  the  final  system  was, 
therefore,  used  extensively  as  the  only  documentation  aid 
for  the  system. 

The  second  part  of  the  verification  procedure  was  to 
identify  inconsistencies,  non-intuitive  design  features-,  or 
contentions  that  were  made  obvious  through  the  application 
of  the  decomposition  methodology. 

8 . 1  Design  Overview  of  the  Sample  Operating  System 

The  description  of  the  Sample  Operating  System  by 
Madnick  and  Donovan  included  a  design  overview,  which  closely 
represented  the  major  design  decisions.  The  design  overview 
is  presented  to  highlight  both  the  design  philosophy  and  the 
intent  of  the  system  designers. 

"The  design  of  the  Sample  Operating  System  follows 

0  fl 

closely  the  framework  presented  in  (Fig.  8.1).  " 

*  —  -  _ 

Madniok  and  Donovan ,  p.19. 


.  "We  build  our  concept  of  an  operating  system  around 
a  process .  We  recognize  that  there  are  certain 
requirements:  necessary  to  support  processes.  A  process 
in  the  proper  environment  could  call,  certain  basic 
functions.  Unfortunately,  most  present-day  hardware 
does  not  provide  these  basic  functions." 

"Thus,  our  first  design  task  is  to  build  basic 
functions  (extended  machine  for  process  support) .  These 
comprise  the  nucleus  or  Kernel  of  the  operating  system. 
Examples  of  these  basic  functions  are  the  P-V  operations, 
basic  multiprocessing  support,  and  traffic  controlling i 
The  reader  can  think  of  these  software  functions  as 
being  executed  in  the  same  way  as  hardware  instructions . 

"It  is  best  to  think  of  the  Kernel  as  being  an 

extended  machine  that  consists  of  a  number  of  extended 

% 

instructions.  In  this  implementation,  the  extended 
instructions  are  accomplished-,  by  means  of  the  supervisor 
call  instruction . " 

"....Certain  operating  system  functions  can  be 
provided  in  the  form  of  special  system  processes  rather 
than  system  primitives .  In  this  sample  operating 
system,  there  are  several  such  processes,  including  the 
supervisor  processes  (job  stream  handlers)  and  the 

device  handler  processes . The  hierarchical 

construction  of  the  Kernel  is  such  that  each  successive 
level,  from  the  bottom  up,  depends  only  on  the 
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existence  of  .those  levels  below  it,  and  not  on-  those 
above  it.  This  approach  has  the  advantage  of  pedago¬ 
gical  clarity,  offers  debugging  ease,  and  may  be 

29 

relevant  to  the  development  of  new  theory." 

From  Figure  8.1  one  may  discern  five  levels  and  layers  (or 
modules)  of  the  Sample  Operating  System. 


Levels 


-Process  Management,  lower  module  (lowest) 
-Memory  Management  Module 
-Process  Management,  upper  module 


r-  Device  Management  Module 

Layers 

L-  Supervisor  Process  Module  (highest) 

The.  functions  of  process  management  have  been  split 
into  a  lower  module  and  an  upper  module  because  certain 
functions  of  process  management  (upper  module)  depend  upon 
memory  management  functions ,  but  memory  management  itself 
depends  on  certain  process;  management  routines'  that  must  be 
in  a  module  below  memory  management.  Clearly  this  step 
increases  the  pedagogical  clarity  of  operating  system.  It. 
is  also  noted  that  the  Sample  Operating  System  has  no 
.spooling  process  nor  information  management  (file)  system. 

An  examination  was  conducted  of  the  functions  of  each 
level  and  layer  in  the  heirarchical  operating  system 
structure  of  the  Sample  Operating  System  to  determine  if 
they  correspond  to  the  functions  of  the  subproblems  identi¬ 


fied  in  the  decomposition  methodology. 
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Madniok  and  Donovan ,  pp. 383-335. 


Level  1 


-  130  - 


8 . 2  Functional  Comparison  of  the  Levels  and  Layers  of  the 
Sample  Operating,,  System  with  the . Subprobiems  Generated 
By  the  Decomposition  Methodology 

•8.2.1  PROCESS  MANAGEMENT  (LOWER)  MODULE  COMPARED  WITH 

PROCESS  CONTROL  AND  PROCESS  SYNCHRONIZATION  MECHANISM 
SUBPROBLEMS : 

The  functional  description  of  the  process  management 
(lower)  module  is  as  follows: 

The  module  schedules  and  runs  processes  that  are 
eligible  to  run  and  provides  the  basic  primitives  for 
synchronization  of  processes. 

These  functions  are  wholly  contained  in  the  two  main  sub¬ 
problems  of  Process  Control  and  Process  Synchronization 
mechanism.  The  process  control  main  subproblem  as  described 
in  section  7.3.3  is  concerned' with  the  functions  necessary 
to  control  all  processes  in  the  operating  system.  This 
main  subprOblem  decomposed  into  three  subproblems;  specifi¬ 
cally,  process  scheduling,  system  initiated  interrupt 
handler,  and  user  initiated  interrupt  handler.  The  process 
scheduler  is  concerned  with  the  procedure  for  scheduling 
eligible  processes  and  corresponds  to  the  process  scheduler 
of  the  Sample  Operating  System.  The  system  and  user 
initiated  interrupt  handlers  define  the  functions  necessary 
for  process  multiplexing  by  the  operating  system  and  the 
user.  These  functions  essentially  distinguish  between 
eligible  and  ineligible  processes. 


The  second  main  subproblem  included  in  the  comparison 


is  the  process  synchronization  mechanism>  As  described  in 
section  7.3.8  this  main  subproblem'  is  concerned  with  the 
specific  function  of  the  synchronization  mechanism  and 
directly  corresponds  with  the  "basic  primitives  for  synchro¬ 
nization  of  processes”  described  in  the  process  management 
(lower)  module  of  the  Sample  Operating  System. 


8.2.2  MEMORY  MANAGEMENT  MODULE  COMPARED  WITH  THE  MEMORY 
ALLOCATION  MAIN  SUBPROBLEM  AND.  OPERATING  SYSTEM 
INFORMATION  TABLES  SUBPROBLEM: 

The  functional  description  of  the  memory  management 
module  is  as  follows: 

This  module  performs  the  operations  necessary  for 
the  dynamic  allocation  and  freeing  of  memory  for,: 

a)  job  allocation. 

b)  operating,  system  dynamic  allocation. 

The  allocation  functions  defined  for  job  and  system  needs 
correspond  to  the  functions  described  in  the  memory 
allocation  main  subproblem  and  operating  system  information 
table  subproblem  as  described  in  section  7.3.6  was  concerned 
with  the  protocols  for  memory  allocation  and  directly 
correspond  to  the  functional  description  of  the  memory 
management  module  for  job  partitions. 

The  operating  system  information  table  subproblem  was 


decomposed  from  the  interprocess  communication  main  subprob¬ 
lem.  As  described  in  section  7.4,2  this  subproblem  is 
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concerned  with  the  use  of  information  tables;  to  monitor  and 
control  processing  and  corresponds  to-  the  memory  management 
module  allocation  functions  for  memory  for  operating  system 
dynamic  allocation.  It  is  noted  that  the  decomposition 
methodology  defined  the  functions  of  operating  system 
dynamic  allocation  of  memory  for  information  tables  as  a 
subproblem  of  interprocess  communication;  whereas  the 
designers  of  the  Sample  Operating  System  treated  the  func¬ 
tions  as  a  subproblem  of  memory  management.  The  conceptual 
distinction  is  as  follows; 

a)  Decomposition  of  the  information  table  requirements 
as  a  subproblem  of  interprocess  communication 
resulted  from  an  assessment  of  "What"  was  the 
function  of  information  table?  The  function  is, 

of  course,  to  monitor  and  control  processing  by 
communicating  the  status  of  resources  thru  tables 
shared  among  the  processes  of  the  operating  system  • 

b)  The  treatment  of  the  dynamic  allocation  of  memory 
for  information  tables  (operating  system  dynamic 
allocation)  resulted  from  an  assessment  of  how  is 
the  information  table  requirement  to  be  implemented? 
Since  the  function  requires  a  significant  amount  of 
memory  allocation,  it  was  considered  a  subproblem 
of  the  memory  management  module. 

The  interdependencies  among  requirements  were  assessed 
in  an  implementation  independent  environment.  The  applies- 
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tion  of  the  decomposition  methodology,  a  framework  (i.e. , 
subproblems)  in  which  alternative  implementation  schemes 
may  be  thoroughly  investiaged.  For  the  final  design,  the 
information  table  subproblem  was  combined  with  the  memory 
allocation  subproblem  to  form  the  memory  management  module 
of  the  .Sample  Operating  System. 

This  comparison  raised  the  following  issue; 

If  a  main  subproblem  decomposes  upon  the  second 
decomposition  should  one  assess  the  main  subproblem  as  com¬ 
posed  of  several  subproblems  or  should  one  assess  the 
subproblems  as  independent  design  problems  at  the  same 
level  as  main  subproblems? 

The  purpose  of  decomposition  methodology  is  to  provide 
a  framework  of  subproblems  in  which  the  designer  is  free  to 
optimize  the  subproblem  by  investigating  alternative 
implementation  schemes.  The  framework  is  meant  to  provide 
a  structure  for  the  designer,  but  not  to  impose  additional 
constraints  upon  the  designer's  freedom.  Since  the  assess¬ 
ment  of  subproblems  as  independent  design  problems  offered 
more  flexibility  to  the  designer,  one  should,  therefore, 
assess  subproblems  resulting  from  a  second  decomposition  at 
the  same  level  as  main  subproblems.  In  terms  of  the 
previous  comparison,  treating  the  operating  system  informa¬ 
tion  table  subproblem  within  the  structure  of  the  inter¬ 
process  communication  main  subproblem  would  have  added  a 
constraint  upon  the  system  designer. 
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8.2.3  PROCESS  MANAGEMENT.  (UPPER)'  MODULE  COMPARED  WITH  THE 
PROCESS  CREATION  SUBPROBLEM  AND  THE  MESSAGE  FACILITY 
SUBPROBLEM: 

The  functional  description  of  the  process  management 
(upper)  module  is  as  follows: 

"The  module  provides  routines  for: 

a)  the  control  of  processes;  specifically,,  creation 
and  deletion. 

b)  interprocess  communication  with  buffered 
messages. " 30 

These  functions  correspond  to  the  functions  of  the 
process  creation  subproblem  and  the  message  facility  sub¬ 
problem.  The  process  creation  subproblem,  as  described  in 
section  7.3.4,  is  concerned  with  the  protocols  for  process 
creation,  and  correspond  directly  with  the  functions  of  this 
operating  system  module. 

The  second  subproblem  included  in  this  comparison  is 
the  message  facility  subproblem  which  was  decomposed,  from 
the  interprocess  communication  main  subproblem.  For  reasons 
stated  in  the  last  section,  the  message  facility  subproblem 
was  treated  as  an  independent  design  problem  at  the  level 
of  a  main  subproblem.  Its  functions,  as  described  in 
section  7.4.2,  are  concerned  with  the  existence  and  use  of 
a  message  facility  by  all  process  for  interprocess  communi¬ 
cation.  These  functions  correspond  with  the  functions  of 
"interprocess  communication  with  buffered  messages"  as 

J  /O  -  -  -  .  . 

Madniok  and  Donovan p.  388. 
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specified  in  the  process  management  (upper)  module. 

8.2.4  DEVICE  MANAGEMENT  MODULE  COMPARED  WITH  THE  DEVICE 
MANAGEMENT  FUNCTION  SUBPROBLEM: 

The  functional  description  of  the  device  management 
module  is  as  follows: 

"This  module  provides  the  routines  necessary  to 

issue  the  appropriate  input/output  commands  to 

extended  devices.  A  special  portion  of  the  device 
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management  routine  handles,  interrupts." 

These  functions  correspond  to  the  functions  contained  in 
the  device  management  function  subproblem.  As  described  in 
section  7.3.7,  this  subproblem  is  concerned  with  the 
functions  required  for  device  management,  specifically the 
procedures  for  requesting  resources  and  I/O  by  the  user. 

8.2.5  SUPERVISOR  PROCESS.  MODULE  COMPARED  WITH  THE 
SUPERVISOR  PROCESS  MAIN  SUBPROBLEM:' 

As  implied  by  the  title  of  this  section,  both  the 
module  and  the  .main  subproblem  are  nearly  identical . 

The  functional  description  of  the  supervisor  process 
module  is  as  follows: 

"This  module  serves  as  the  job  scheduler.  It  can 

use  all  the  functions  provided  by  the  previous  modules 
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to  create  an  interface  for  the  process  of  user  jobs." 

These  functions  correspond  exactly  with  the  functions  of  the 

_ 

Madniok  and  Donovan ,  p.389. 
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Madniok  and  Donovan ,  p.389. 
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supervisor  process  main  subproblem.  As  described  in  section, 
7 . 3.1,  the  supervisor  process  is  concerned  with  the 
generation  of  a  multi-programming  environment  for  user 
processes;  It  is  that  process  which  prepares  and  schedules 
user  jobs  for  execution., 

8.2.6  SUPERVISOR  CALL  HANDLER  COMPARED  WITH  THE  EXTENDED 
MACHINE  INSTRUCTION  MECHANISM  MAIN-  SUBPROBLEM: 

Madnick  and  Donovan  describe  an  additional  group  of 
routines  which  are  not  reflected  in  the  heirarchical  opera¬ 
ting  system  structure  as  follows : 

"Several  routines  don't  conveniently  fit  our 
'  heirarchical  level  structure.  The  most  notable  case 
is  the  SVC  handler  used  to  activate  the  extended 
machine  instructions  and  transfer  between  levels." 

The  requirements  for  these  routines  are  wholly  contained  in 
the  functional  description  of  the  extended  machine  instruc¬ 
tion  mechanism  main  subproblem.  As  described  in  section 
7.3.2/  the  main  subproblem  is  concerned  with  the  character¬ 
istics  and  protocols  for  the  use  of  the  extended  machine 
instructions.  Since  these  instructions  may  be  called  by  any 
level  or  layer  of  the  operating  system,  they  cannot  be 
generalized  into  the  heirarchical  system  structure. 

8.2.7  SUMMARY  OF  THE  FUNCTIONAL  COMPARISON: 

The  comparison  of  the  functions  of  the  modules  for  the 
Sample  Operating  System  with  the  functional  description  of 
the  requirements  contained  in  each  design  subproblem  defined 


by  the  description  methodology  has  yielded  several 
instruction  insights.: 

.  The  rationale  for  treating  design  subproblems, 
resulting  from  the  second  decomposition  of;  a  main 
subproblem,  as  independent  design  problems  at  the. 
level  of  main  subproblems  was  developed.  Since 
independent  design  problems  provide  a  framework, 
yet  impose  fewer  constraints  upon  the  designer, 
the  design  process  should  deal  with  subproblems 
as  independent  design  problems  to  be  optimized. 

.  The  decomposition  methodology  identified  a  greater 
number  of  subproblems ,  and  the  subproblems  were 
internally  more  defined,  than  the  levels  and  layers 
of  the  final  operating  system  design.  For  instance 
the  process  management  (lower)  module  has  three 
distinct  functions; 

a)  schedules  and  run  processes; 

b)  defines  eligible  processes; 

c)  provides  basic  system  primitives. 

The  decomposition  methodology  identified  four  sub¬ 
problems  to  correspond  with  the  function  process 
management  (lower)  module;  specifically: 

a)  process  scheduling  function; 

b) .  system  initiated  interrupt  handler; 

c)  user  initiated  interrupt  handler; 

d)  process  synchronization  mechanism. 
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The  designer  now  has  at  his  disposal  a  framework  in 
which  the  functions  of  each  subproblem  are'  clearly  defined, 
internally.  The  designer  next  investigates  alternative 
implementation  schemes  to  satisfy  the  requirements  of  each 
subproblem.  In  addition,  the  interfaces  between  pairs  of 
subproblems  are,  clearly  defined  so  that,  in  the  case  of 
system  and  user  initiated  interrupt  handler,  common  functions 
or  processing  may  enable  concurrent  implementation  schemes 
for  subproblems  so  closely  related. 

Therefore,  the  designer  is  presented  with  a  clearly 
defined  framework  of  subproblems  which  he  may  choose  to 
agglomerate  into  larger  modules  to  satisfy  the  design 
problem. 

The  next  section  will  investigate  some  of  the  Inconsis¬ 
tencies  identified  by  the  decomposition  methodology. 

8.3  Inconsistencies  Identified  in  the  Comparison  of  the 

Sample  Operating  System  and  the  Decomposition 

rMethodology 

The  inconsistencies  identified  in  the  comparison  of  the 
Sample  Operation  System  and  the  decomposition  methodology 
were  of  two  types.  First,  the  final  design  of  the  Sample 
Operating  System  contained  certain  features  that  were  not 
reflected  in  the  results  of  the  decomposition  methodology. 
Second,  process  of  requirements  definition,  interdependency 
assessment,  and  application  of  the  decomposition  methodology 


identified  unresolved  contentions  or  conflicts  in  the 
Sample  Operating  System. 

8.3.1  FEATURES  OF  THE  FINAL  DESIGN  OF  THE  SAMPLE  OPERATING 
SYSTEM  NOT;  REFLECTED-  IN  THE  RESULTS  OF  THE 
DECOMPOSITION'  METHODOLOGY : 

The  main  feature  not  captured  in  the  decomposition 
methodology  was  the  heirarchical  nature,  of  the  Sample 
Operating  System.  This  is  significant  because  the  heirarchi¬ 
cal  design  incorporates  a  strictly  limited  interfacing 
protocol  between  the  levels^  and  layers  of  the  Sample  Oper¬ 
ating  System  in  which  each  successive  level  from  the  bottom 
up,  depends  only  on  the  existence  of  those  levels  below  it. 

It  can  be  argued  that  the  heirarchical  construction 

technique  was  a  design  decision  made  in  a  later  stage  of  the 

design  process  since  it  satisfies  the  objective  of  the 

design;  that  is,  the>  .modular  and  heirarchically  structured 

design  is  pedagogically  effective.  Yet,  the  interface 

protocols  are  very  restricting  and  the  separation  of  the 

process  management  module  into  an  upper  and  lower  module 

» 

were  dictated  by  existence  dependence  of  upper  levels  upon 
lower  levels.  Therefore,  an  investigation  was  made  of  the 
linkages  between  subproblems  to  determine  if  the  heirarchical 
nature  of  the  Sample  Operating  System  could  be  inferred 
"post  facto"  from  the  facilities  available  in  the  decomposi¬ 
tion  methodology. 

The  results  of  the  previous  section  were  used  to 


identify  when  subproblems  and  modules  were  equivalent; 

Final .Design  Decomposition  Methodology 

Process  Management  (lower)  Process  Scheduling. 

Module 

System  Initiated  interrupt 
Handler 

User  Initiated  Interrupt 
Handier 

Process  Synchronization 
Mechanism 

Memory  Management  Module  Memory  Allocation 

Operating  System  Information 
Tables 

Process  Management  (upper)  Process  Creation 

Module 

Message  facility 

Device  Management  Module  Device  Management  Functions 

Supervisor  Process  Module  Supervisor  Process 

Supervisor  Call  Handler  Extended  Machine  Instruction 

Mechanism 

Since  the  linkages  between  subproblems  are  assessed  in 
an  undirected  manner,  and  are  symmetric,  the  actual  direction 
of  the  linkages  could  not  be  determined.  Therefore,  no 
statement  could  be  made  in  regard  to  an  ''upper''  module 
calling  a  "lower"  module. 

A  comparison  was  made  of  the  raw  number  of  linkages 
between  subproblems.  The  tabulation  of  this  comparison  is 
presented  in  Appendix  K.  It  was  expected  that  some  sort  of 
trend  might  be  established  with  the  number  of  linkages, 
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cumulated  first  by  .subproblem,  second  by  module.  Specifi¬ 
cally,  since  the  process  management  (lower)  module  is  the 
closest  to  the  bare  machine,  it  must  be  used  frequently  arid, 
therefore,  one  would  expect  the  number  of  linkages  to  it  to 
be  relatively  large.  Conversely,  the  device  management 
module  is  <a  layer  of  the  operating  system?  therefore,  its 
level  of  interfacing  in  raw  numbers,  should  be  considerably 
less  than  the  previous  example. 

The  results  of  'the  comparison  are  as  follows,: 

.  The  average  number  of  linkages  per  subproblem  equalled, 
16.18. 

.  Process  management  (lower)  module  had  the  greatest 
number  of  linkages,  yet  no  trend  could  be  established. 
That  is,  the  number  of  linkages  exhibited  no  signi¬ 
ficant  trend  as  one  approached  closer  to  the  bare 
machine . 

.  The  fact  that  the  process  management  (lower)  module 
had  a  greater  number  of  linkages  was  due'  more  to  the 
fact  that  it  was  composed  of  four  subproblems,  rather 
than  by  any  existence  dependency. 

Therefore,  the  decomposition  methodology  gave  no  inferrence 
of  a  heirarchically  structured  operating  system. 

8.3.2  CONTENTIONS  IDENTIFIED  DURING  THE  APPLICATION  OF  THE 
DECOMPOSITION  METHODOLOGY: 

During  the  process  of  requirement  definition,  inter¬ 
dependency  assessment,  and  application  of  decomposition 
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methodology,  numerous  unresolved  issues  were  discovered 
which:  could'  lead  to  contentions  or  conflicts  during  imple¬ 
mentations  .  These  issues  were-  involved  with  the  implementa¬ 
tion  of  system  requirements  and  were  the  result  of  the 
application  of  worst  case  usage  of  the  system  to  determine 
if  the  requirements  set  was  complete.  The  unresolved 
contentions  were  as  follows : 

..  The  operating  system  must  have  some  finite  limit  in 
the  number  of  jobs  that  it  will  accept  before  a 
critical  resource  is  fully  allocated.  The  limit  could 
involve  memory,  dedicated  devices,  or  IBM  System/360 
protection  keys.  The  limit  was  not  established  in 
the  requirements,  nor  was  any  priority  specified  to 
determine  which  is  the  critical  resource. 

.  The  message  requirement  number  56  states:  "Any 
number  of  messages,  for  a  given  process,  may  be  queued 
while  waiting  to  be  read  by  the  process."  Since  the 
memory  area  for  buffered  messages  is  dynamically 
allocated,  it  is  conceivable  that  one  process  could 
do  nothing  but  write  messages  to  itself.  Carried  to 
an  extreme  all  of  memory  could  be  consumed  by  the 
process  in  which  event  the  system  would  become 
deadlocked.  Therefore,  some  finite  limit  should1  be 
placed  on  the  number  of  messages  which  a  process  may 


have  enqueued  before  it  is  forced  to  read  the  messages. 
.  Requirement  24  states:  "Ready  processes  are  scheduled 
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in  simple  round-robin  fashion  by  the  process- 
scheduler.  ”  The  process  scheduler  checks  an  informa¬ 
tion  table  to  determine  if  a  given  process  is  ready; 
if  it  is  not  ready,  the  process  scheduler  checks  the 
next  process  in  a  sequential  chain.  It  is  conceivable 
that  all  processes  in  the  system  may  become  blocked 
at  the  same  time.  Therefore,  the  process  scheduling 
function  must  include  some  mechanism  to  first  deterr* 
mine  that  all  processes  are  blocked  and  second,  to 
attempt  to  resolve  the  situation. 

The  preceeding  contentions  became  obvious  during  the 
decomposition  methodology.  The  lack  of  further  contentions 
was  not  meant  to  imply  that  no  further  contentions  exist  in 
the  Sample  Operating  System.  The  decomposition  methodology 
contained  no  rigorous  methodology  to  determine  if  a  complete 
and  consistent  set  of  requirements  had  been  defined. 

8. 4  Summary 

The  final  design  of  the  Sample  Operating  System  was 
verified  by  the  results  of  the  second  iteration  of  decompo¬ 
sition  methodology.  The  decomposition  methodology  identified 
eleven  well-defined  subproblems  which  corresponded  in  a 
consistent  manner  with  the  functions  of  the  six  levels  and 
layers  and  SVC  instructions  handler  of  the  final  design  of 
the  Sample  Operating  System. 

The  decomposition  methodology  did  not  infer  the  heir- 


archical  .structure  .of  the.  final  design.  However./  the 
identification,  of  linkages  between  pairs  of  subproblems 
•explicitly  defined  the  interfaces  which  were  incorporated 
into-  the  modules  of  the  final  design. 

The  procedures  involved  in  the  decomposition  methodology 
that  is,  requirements  definition,  interdependency  assessment 
and  decomposition  methodology,  include  no  rigorous  attempt 
to  ensure  that  a  complete  set  of  requirements  was  defined 
for  the  Sample  Operating  System. 

The  next  chapter  will  present  recommendations  for 
improvements  of  the  methodology  based  upon  the  analysis  of 
the  Sample  Operating  System. 
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CHAPTER  IX 

CONCLUDING  STATEMENTS  CONCERNING  THE 

Applicability  of  the  decomposition,  methodology 

TO  TP  DESIGN  PROCESS  AND  RECOMMENDATIONS 
FOR  IMPROVEMENT 


The  purpose  of  this  chapter  is  to  take  a  retrospective 
view  of  the  decomposition  methodology  applied  to  the  Sample 
Operating  System..  Based  on  the  experience,  conclusions 
will  be  discussed  concerning/  the  applicability  of  the 
decomposition  methodology  to  the  design  process., 


9.1  Objectives  of  the  Methodology 

The  objective  of  the  application  of  the  decomposition 
methodology  was  to  support  the  designer  in  the  architectural 
design  phase  by  providing  the  designer  with  a  framework  in 
which  the  design  problem  can  be  studied  in  a  well-defined 
and  organized  fashion.  The  architectural  design  phase 
consists  of  a  well-structured  series  of  activities  that  the 
design  engineer  should  perform  in  order  to  achieve  a  better 
understanding  of  the  design  problems  at  hand,  as  well  as  to 
avoid  implicit  and  unwarranged  preconceptions  that  can  bias 
the  eventual  design  significantly.  The  decomposition 
methodology  supports  the  architectural  design  phase  by 
clustering  the  global  system  requirements  into  subproblems; 
The  methodology  then  does  not  purport  to  provide  a  best 
answer,  since  the  techniques  are  satisfying  rather  than 
optimizing. 


The  purpose  of  this  chapter ,  the  methodology  must  be 
expanded  to  include  the  following  stages: 

.  Requirements  definition  stage; 

.  interdependency  Assessment  'Stage; 

.  Application  of  the  Decomposition  Methodology  Developed 
by  Andreu. 

The  methodology  supports  the  design  process  by 
decomposing  system  requirements  into  subprobleras.  The  sub¬ 
problem  concept  narrows  the  scope  of  consideration  of  the 
design  engineer  to  more  specific  well-defined  areas  of 

concern i  But  as  pointed  out  by  Leopold,  Svendsen,  and 
33 

Kloehn,  subproblems  create  more  levels  of  management  and 
organizations  produce  designs  which  are  copies  of  the 
communication  structure  of  the  organization.  The-  result  can 
be  that  the  solution  to  the  design  problem  becomes  a  series 
of  compromises  based  oh  political  expediency  rather  than 
on  technical  objectivity.  Any  methodology  must  provide  for 
better  communication  based  on  technical  objectivity  to 
satisfy  the  design  problem. 

The  decomposition  methodology  facilitates  consideration 
and  discussion  of  the  system  requirements,  system  objectives 
and  constraints  early  in  the  design  process.  In  fact,  the- 
methodology  forces  the  user  to  conduct  a  pair-wise  assess¬ 
ment  of  the  interdependencies  of  all  requirements.  This  is 

^^Reuven  Leopold ,  Edward  C.  Svendsen ,  and  Earvey  Kloehn , 
"Warship  Design/ Combat  Subsystem  Integration  -  A  Complex 
Problem t  Unneoessai'ily  Overcomplicated ",  Naval  Engineers 
Journal  CAuaus-t  1972)  p.44. 
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significant  in  two  ways-: 

.•  An  exhaustive  pair-wise  assessment  of  interdependen¬ 
cies  executed  in  a  top-down  manner,  forces  one  to 
think  in  terms  of  conceptual  models  freeing  the 
designer  of  his  dependencies,  upon  tradition-bound 
designs. 

i  The  decomposition  methodology  causes  the  elimination 
of  prevalent  misconception  or  traditional  design 
practices  by  displaying  the  complex  interrelation¬ 
ships  which  heretofore  were  unavailable  to  the 
designer . 

The  usefulness  of  the  methodology  was  verified  by  the  results 
of  the  application  to  the  design  of  the  Sample  Operating 
System  as  stated  in  section  8.4.  Yet- the  experience  gained 
in  the  application  of  the  methodology  suggested  improvements 
to  all  three  phases  of  this  methodology  to  improve  both  its 
effectiveness  and  to  increase  the  scope  of  the  applicability. 
The  next  -section  of  the  chapter  will  present  those  recommend¬ 
ations  for  improvement. 

9 . 2  Recommendations  for . Improvement 
9.2.1  SUGGESTIONS  TO  IMPROVE'  COMMUNICATION: 

The  decomposition  methodology  is  but  a  small  supporting 


tool  in  the  overall  design  process;  specifically,  in  the 
architectural  design  phase.  The  most  time-consuming  stages 
of  the  methodology  were  the  requirements  definition  stage 
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and  interdependency  assessment  stage.  The  functions 
required  in  each  Stage  were  hand-written  and  the  analysis 
was  performed  off-line.  The  lack  of  any  text  facility  pre¬ 
cluded:  an  on-line  assessment  of  design  problems.  The  time 
required;  to  perform  the  stages  of  methodology  could  be 
reduced,  and  the  methodology  improved  if  the  three  stages 
could  be  made  completely  interactive  by  the  addition  of  a 
facility  for  limited  documentation  statements.  The  specific 
documentation  statements  needed  are,  defined  in  the  supplement 
sections. 

9.2.2  REQUIREMENTS.  DEFINITION : 

The  problems  associated  with  generating  well-defined 
requirements  statements,  even  for  an  existing  system,  are 
well-known.  This  stage  of  the  decomposition  methodology  . 
represented  the  greatest  expenditure  of  time  and\energy  for 
this  thesis.  As  described  in  section  2.1,  the  functional 

specification  phase  of  the  design  process  is  receiving 

.  .  34 

considerable  attention  from  researchers.  Sid  Huff  has 

described  a  template  format  for  requirements  definition  which 

recognizes  six  distinct  statements  built  upon  three  basic 

language  constructs.  The  Pasic  constraints  consist  of : 

objects:  which  are  items  or  activities  such  as  item  - 

memory  activity  -  allocated. 

modifiers:  which  are  strings  of  English  adjectives  that 
describe  the  object.  . 

_ 

Sidney  Ruff 3  " An  Approach  to  Constructing  Functional 
Requirement  Statements  for  "Preliminary  System  Design";  unpub¬ 
lished  report ,  MIT  Sloan  School ,  April,  1978 ,  pp.6-7. 


imperatives:  which  indicate  the  nature  of  rela t ions  hipsr. 

Only  two-  imperatives  are  recognized  “ 
can:  implying  conditional  capability. 
will:  must  be  fulfilled, 

These  constructs  are  used  to  generate  six  templates  which  are 
generic  types  of  requirement  statements.  They  consist  of  the 
following: 


Properties:  a  feature  of  the  system. 

Treatments:  an  operation;  that  is  done  to  an  object. 
Timing 

Relationship:  objects  may  be  temporarily  related. 
Order 

Statements:  order  relation#  such  as#  equal  to. 
Measure:  ‘consisting  of  a  parameter  and  a  unit. 


For  example i 


Memory 


will  be i allocated 


in  2K  blocks 


item  object 


imp  activity  object  modifier 


The  template  format  is  a  useful  structuring  tool  for 
requirements  definition  which  may  serve  to  identify  ambi¬ 
guities  or  errors.  The  primary  benefits  of  the  template 
format'  to  the  decomposition  methodology  are: 

.  It  would  provide  a  concise,  well-defined  requirements 
statement  which  could  be  generated  and  stored  on-line 
using  a  menu  of  constructs. 


.  It  would  be  useful  for  determining  interrelationships 


sines-  the  statements-  consist  of  well-defined  key 
words.. 

>  Completeness  of  requirements  set  could  be  verified 
through  the  use  of  simple  algorithms  which  would 
check  fOr.  the  existence  of  capabilities  clearly 
defined  in  the  property  statements. 

9.2.3  ASSESSMENT  METHODOLOGY: 

The  greatest  weakness  Of  the  decomposition- •methodology 
is  the  fact,  that;  the  binary  assessment  procedure  is<  simplis¬ 
tic  and;  therefore,  constraining.;  The.  binary  assessment 
procedure  does  not  allow  any  sort  of  sensitivity  analysis  of 
weighting  of  the  interdependencies  and  does  not  allow  for 
the  representation  or  solution  of  an  objective  function. 

The  lack  of  an  ability  to  represent  an  objective  func¬ 
tion  resulted  in  the  separation  of  the  design  philosophy  and 
constraint  statements  from  the  requirements  set  that  was 
analyzed  for  interdependencies.  All  that  one  could  say  was 
that  the  design  philosophy  and  constraint  statements  must 
apply  to  every  other  requirement  in  a  global  sense  or  they 
apply  not  at  all.  If  the  interdependencies  could  be  weighted 
then  it  would  be  possible  to  assess  the  relative  level  of 
impact  and  to  establish,  an  objective  function  to  be  satisfied 
This  objective  function  could  be  satisfied  by  a  facility  to 
describe  conceptual  models  or  mathematical  relationships  on¬ 
line.  The  mathematical  relationship  would  be  of  the  form  of 
an  expression  interrelating  different  indices  or  measures 
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used  to  measure  the  degree  of  satisfaction  of  an  objective 
function  provided  by  each  interrelationship  between  require¬ 
ments.  The  constraints  upon  the  design- must  also  be 
represented  as  limits  on  certain  criteria  within  which  the 
final  values  selected  for  a  system  .must  fall.  Ideally,  all 
indices  used  to.  measure  satisfaction  of  an  obj  ective  function 
must  be  reduced  to  a  common  denominator.  For  instance,  the. 
objective  function  may  be  stated  in  terms  of  response  time 
(Ttotal')  *  -res?onse  time  is  related  to  CPU  time  for 

execution  (Tcpu),  Input/Output  time  (T^q)  ,  waiting  or 
blocked  time  (Tw) .  Therefore,  the  objective  function  could 
be  stated  in  terms  of  TtQta^  »  Tcpu  +  T.jy0  +  Tw  .  Inter¬ 
relationships  among  requirements  would  be  assessed  according 
to  a  conceptual  model  involving  a  time  index.  The  decompo¬ 
sition  methodology  could  then  provide  a  relative  measure  of 
the  satisfaction  of.  the  objective  function  by  each 
decomposition. 

9,2.4  ADDITIONAL  FEATURES:. 

.  Design  is  essentially  an  art,  which  is  heavily  dependent 

i 

upon  She's  background  and  biases.  It  would  be  interesting 

I 

although  not. 'necessary,  to  implement  a  facility  in  the 
decomposition  methodology  which  would  enable  a  user  to  input 

'l 

his  own  idea  of  the  "best"  decomposition  in  the  form  of  sub¬ 
problems.  The  decomposition  package  should  then  generate  a 
measure  for  the  proposed  decomposition  and  would  serve  as  a 
relative  grade  to  the  designer  vis-a-vis  the  system-generated 
"best"  decomposition. 


9.  3  -Summary 

This  study  has  demonstrated'  that  the  decomposition 

methodology  proposed  by  Dr.  Andreu  is  a  useful  technique 

providing  a  framework  for  the,  designer  for  use  in  the 

architectural  design  stage.  It  is  recognized  that  this 

methodology,  is  a  first  step  in  the  right  direction.  The 

usefulness  of  the  first  step  was  recognized  by  Mandei  and 

35 

Chryssostomidis : 

"Unfortunately,  the  direct  contribution  of  the 
computer  to  design  methodology  is  small  because  the 
capabilities  provided  by  the  computer  do  not  augment 
the  user's  ability  as  a  designer  but  rather  as  an 
analyst.  For  this  reason,  it.  is  felt  that  research 
leading  to  documentation  of  an  improved  large  system 
design  methodology  that  also  takes  advantage  of  today's 
tools  is  both  timely  and  worthwhile." 

The  value  of  the  decomposition  methodology  will  improve  as 
the  results  of  its  application  are  verified  through  similar 
research  arid  improvements1  to  the  facilities  are  implemented 
by  designers  in  search  of  a  better  world. 


35 

c 


Mandei  and  Chryssostomidis 3  v,85. 


•1. 
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FORMAL  SPECIFICATION  OF  EVALUATION  PARAMETERS:36 
Given  a  graph  as  a  pair  (X,L) ,  where 

X  :  {x|x  =  1,2,....-.  | X | } ,  the  set  of  jxj  objects,** 

and 

L  :  |'jjL  j  exists  if  a  link  joins  objects  i -and  j.s  X}> 

the  set  of  links, 


Define 

A  :  a. .  a, u  *  1  If  . .  exists,  0  otherwise  ,  the 
i3  13  xj 

adjacency  matrix  associated  with  the  graph. 

Then,  the  strength  S^  of  a  subset  X^CX  can  be  expressed 
as: 


Si  = 


l  <  f X.  1,-1) 

k,  AeX .  **  1 

k<A  1 _ 

iX.idX.j-l) 


while  the  coupline  C. .  between  the  subsets  X.  and  X.CX, 

AJ  J "" 

^ ^ | X |  is  used  to  indicate  the  cardinality  of  set  X. 

zs 

AndreUi  pp.  100-101. 


p  p 

M  *  Z  S.  Z  C.  . 

i*l  1  i*l  13 

j*i+l 

The  behavior  of  M  is  such  that  the  higher  its  value, 
the  better  the  associated  partition  for  our  purposes,  so  that 
we  should,  in  fact,  search  for  the  partition  with  maximum  M 
value  over  all  possible  partitions  of  the  set  under  decom¬ 
position. 
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ALGORITHM  FOR  THE  IDENTIFICATION  OF  KERNEL  SUBSETS:37 

Recalling,  the  following  definitions:. 

„  The  "core  set"  CS.  associated  with  a  node  o^  to  be  tbe 
set  CSj.  :  {°j  l°j  s*t.  a^  *  1},;  i.e.,  the  set  of  all 

nodes  related  to  o.,  including  o^  itself,  and 
.  The  "connectivity"  of  node  o^  to  be 
c,  =  i.CS.  |;  -  1,  where  by  |x|  we  mean  the  dimension  of 

set  X. 

The  identification  of  kernel  subsets  can  be  done  iteratively 
using  the  following  procedure : 

0)  Set  J  *  0. 

.1)  Compute  ci  Vo.  e  0.  If  c^  *  c .  V  i,j„  set  J  =  J+l? 
KESU(J)  =  0;  stop.. 

2)  Consider  the  k  (>  1,  a  number  specified  a  priori ; 
see  the  end  of  this  section  for  considerations  about 
its  value)  nodes  with  highest  c^..  Without  loss  of 
generality,  assume  that  these  are  the  nodes 

°i/*,*°k* 

3)  Determine  CSi  for  o^  e  {o^,. . . ,0^}. 

k 

4) .  Compute  KS-.  =  (CS.  [  CS.])  o.  e  (o.,, . . .  ,o.) . 

1  1  j=l  J  1  1  K 

5)  Select  o  s  {o.  .  ,ov)  such  that  KS  =  min  (|KS,|) 

p  1  K  pi=l,...,k  1 

?  *7 

'  Andreu,  pp.  125-126, 
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6)  .-Set  J  =  J+l; 

If  |  KS  |  -  |  CS  j .,  set.  DESU  (J)  =  0  and  stop,  else 
P  .P 

set  KESU(J)  =  o  ICS  -  KS  J  . 

p  p  p 

7)  Set  current  set  to: 

0=0-  KESU(J);  if  |0 |  =  0,  stop. 

8)  Recompute  A:- 

old  a. .  if  o.  ,o.  e  0 

A  ♦  fa  a  =  *  ' 

•  *■  i j  1  i j  mark  it  "nonexistent"  otherwise 

‘9)  k  =  k  -  1; 

If  k.  >  1 0,] ,  set  k  =  1 0 1.;  • 

Go  to  1. 

Once  the  procedure  is  executed,  J  Kernel  subsets 
KESU (1) , . . . ,KESU  J  have  been  identified. 
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1.  The  operating  system  must  be  simple >  implementing  a- 
basic  -system  nucleus. 

2.  The  operating  system  must  be  designed  as  ;a  pedagogical 
tool. 

3.  The  operating  sytem  must  be  small;  occupying  fewer 
than  2500  cards  of  assembly  language  statements. 

4.  The  operating  system  is  to  be  implemented  utilizing 
IBM/360  hardware. 

5.  The-  operating  system  must  provide  for  a  multi-program¬ 
ming  environment. 

6.  The  operating  system  must  be  process  oriented. 

7.  The  operating  system  must  run  on  a  machine  that  has  two 
distinct  states. 

8.  All  resource  requests  must  pass  through  the  supervisor 
process. 

9.  System  resources  must  be  allocated  to  a  job,  prior  to 
the  job  being  made  eligible  to  run. 

10.  A  process  must  be  ready  to  run  prior  to  being  allocated 
to  a  processor. 

11.  User  communication  with  the  operating  system  to  VIA  SVC 
Instructions. 

12.  The  operating  system  must  protect  the  user  jobs  from 
each  other. 

13.  The  operating  system  must  utilize  information  tables  to 
monitor  and  control  processing. 


14.  System:  tables  can  be  dynamically  allocated  and 
released . 

15.  Certain  extended  machine  instructions  are  user  callable. 

16.  System  processes  are  re-entrant  and  shared.. 

17.  Extended  machine  instructions  are  executed  in  the 
supervisor  state. 

18.  The  supervisor  process  must  create  and  delete  the 
environment  in  which  a  job  runs. 

19.  Initially  one  process  is.  created  for  each  user's  job; 

20.  Jobs  are  scheduled  on  a  first  come,  first  served 
basis. 

21.  The  job  scheduling  function  must  be  modularized  so 
that  improvements  to  the  system  can  be  easily 
accomplished. 

22.  The  process  scheduler  must  time-slice  CPU  usage  to 
achieve  multi-programming . 

23.  Ready  processes  are  scheduled  in  simple  round-robin 
fashion  by  the  traffic  controller. 

24.  A  process  shall  be  blocked,  and  control  released  to 
the  traffic  controller  when  a  timer  runout  trap  is 
detected. 

25.  A  process  shall  be  blocked  and  control  passed  to  the- 
traffic  controller  when  the  process  must  wait  for 
synchronization  with  another  process. 

26.  A  process  is  blocked  when  it  relinquishes  controller 
to  the  traffic  controller. 


27;.  The  supervisor  routine  must,  reclaim  all  system 
resources  for  a  job  when  the  job  has  completed. 

28.  The  supervisor  process  must  reclaim  all  system 
resources  when  an  error  condition  abnormally  terminates 
a  job..' 

29.  Reference  to  processes  within  a  process  group  is  by 
symbolic  name. 

30.  The  operating  system  must  allocate  memory  for  job 
partitions,  the  size  of  which  is  specified  by  the  user. 

31.  Memory  is  allocated  to  a  job  in  contiguous  2  K 
blocks. 

32.  The  operating  system  may  dynamically  allocate  memory 
to  itself  for  system  processes. 

33.  Memory  is  allocated  using  a  best-fit  algorithm. 

34.  Memory  must  be  protected  to  prevent  the  simultaneous 
allocation  of  a  partition  to  multiple  jobs. 

35.  Free  storage  areas'  are  collapsed  into  contiguous  blocks 
of  memory  whenever  a  partition  is  freed. 

36.  Operating  system  must  supply  a  device  management  system 
which  runs  as  a  separate  process,  one  per  device. 

37.  Device  handler  routines  must  support  multiple  job 
streams  from  card  readers. 

38.  All  devices  are  dedicated. 

39.  The  device  handler  routine  supports  one  card  reader 
per  input  stream. 

40.  Device  handler  must  support  one  line  printer  per  output 


stream. 
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-41-..  Input/outgut  devices  -operate  via  multiplexor  channel. 

42..  The  user  can  provide  his  own  routine  for  non-standard 
devices . 

43.  A  process  synchronization  mechanism  must  be  provided; 

44.  An  interrupt  mechanism  must  be  provided. 

45.  P-V  operations  are  available  only  to  system  processes. 

46.  A  message  facility  .must  be  provided  for  user  processes. 

47.  The  message  facility  is  accessible  by  all  processes. 

48.  The  name  of  the  sending  process  must  be  prefixed  to  a 
message. 

49.  The  receiving  process  must  read  the  name  and  'text  from 
the  originator. 

50.  Messages  are  of  arbitrary  yet  specified  length; 

51.  Any  number  of  messages  may  be  queued  while  waiting  to 
be  read  by  a  process. 

52.  All  messages  are  released  when  a  process  terminates. 

53.  Messages  are  not  receipted  for,  from  receiver  to  sender. 

54.  If  no  messages  are  available  to  a  process  which  expects 
one,  it  goes  blocked. 

55.  User  programs  utilize  a  simplified  job  control  language. 

56.  The  operating  system  .must  accept  input  data  from  the 
user’s  job  stream. 

57.  The  supervisor  process  must  load  the  user's  supplied 
object  code  deck  into  the  user  partition. 

58.  The  user  process  may  dynamically  create  and  destroy 
additional  processes. 
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59 i  Dynamically  created  processes'  run  in  the  same  parti¬ 


tion  as  the  parent  job. 


60.  User  processes  cannot  dynamically  allocate  memory. 


61. 

62. 


64. 


65. 


User  processes  cannot  destroy  system  processes  within 
the  same  .process  group. 

User,  processes  run  in  the  problem  state. 

The  user  process  must  signal  completion  of  the  process, 
to  the  operating  system. 

The  user's  job  can  reference  one  input  device,  one 
output  device,  arid  one  exceptional  device. 

There  is  only  one  supervisor  processes  per  job 


stream. 


Preliminary 


Note:  (1) 

G 


(2) 


( 


APPENDIX  D 

Interdependency  Assessment 
Results 

(s>  Indicates  that  the  requirement 
indicated  supports  the  imple¬ 
mentation  of  the  requirement 
being  assessed. 

(c)  Indicates  that  the  requirement 
indicated  conflicts  with  the 
implementation  of  the  require¬ 
ment  being  assessed. 

Requirements  1  through  4  were  not 

assessed  for  the  reasons  stated  in 

4.1.10. 


The  operating  system,  must  provide  for  a  multi¬ 
programming  environment; 

8 (s) :  The  operating  system  must  allocate  resources,  as 
a  job  is  read  .into  the  system. 

9  (s) :  Resource  allocation  is  performed  as  a  job  is. 
read  into  the  system,  except  for  processor 
allocation. 

16  (sj  :  The  need;  for  pure  procedures  .is  driven  by  the 
need  to  provide  for  a  multi-programming, 
environment . 

ft* 

19.(s) :  The  supervisor  process  creates  one  process  per 
job  initially  in  support  of  multi-programming. 

20  (s)  :  Multi-programming  requires  that  the  jobs  be 
scheduled. 

22  (s) ;  Time  slicing  CPU  usage  facilitates  multi¬ 
programming  . 

34  (s):  Multi-programming,  requires  that  memory  be 

protected  to  prevent  simultaneous  allocations 
of  partitions. 

37  (s);  Device  handler  routine  facilitates  the  reading 
of  multiple  job  streams  from  different  sources. 

43  (s) :  Process  synchronization  mechanism  is  used  to 
coordinate  multi-programming. 

55  (s):  JCL  facility  assists  multi-programming  by 
delineating  jobs  and  specifying  resource 
requirements . 
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65  (s)-:  The  supervisor  process  controls  multi¬ 
programming  environment . 

.6:  Operating  system  must  be  process  oriented. 

.10(5):  The  process  has  certain  resource  requirements 
apart  from  job  level  requirements. 

11  (s):  The  SVC  instruction  support  process  requirements.. 
13  (s)=:  Most  information  is  maintained  at  a  process 
*  level. 

19  (s)  :  A  user  job  begins  as  a  process-, 

22(s) :  Process  environment  requires  the  use  of  a  (traffic 
controller  to  achieve  multi-programming. 

23  (s):  An  algorithm  is  required  for  process  scheduling. 

25  (s):  Multi-process  synchronization  is  a  basic 

function  required  for  a  process  environment. 

26  (s):  Relinquishing  control  to  the  traffic  controller 

is  a  basic  function  of  a  process  environment. 

29  (s):  The  naming  of  process  is  required  as  a  means  of 
identification . 

43  (s):  Process  synchronization  mechanism  is  a  basic 
tool,  for  process  oriented  support. 

46  (s):  The  message  facility  is  a  basic  means  of  inter¬ 

process  communication. 

47  (s):  Message  facility  must  be  available  to  all  user 

processes. 

58  (s) :  Dynamic  process  creation  is  a  basic  function  for 


a  process  environment. 
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7,:  Operating  .system-  must  run-  on  a-  machine  that  has  two 

distinct  states. 

l'l  (s) :  User  communication  via  SVC  instruction  ensures 
that  'the  .user  may  be  restricted-  from,  certain 
privileged,  instructions . 

15  (s) :  Only  certain  SVC  instructions  are  user  callable 

17  (s):  SVC  instructions  explicitly  executed,  in  the 
supervisor  state. 

62  (s)  :  User  programs  run  in  the  problem  state;  hence, 
system  processes  run  in  the  supervisor  state. 

8:  All  resource  requests  must  pass  through  the  supervisor 

process. 

9(s) :  All  resource  requests  must  be  made  prior  to  a 
job  being  eligible  to  run. 

13  (s) ;  Information  tables  contain  the  information 
concerning  resource  allocation. 

27 (s) :  Supervisor  also  reclaims  resources  when  a  job 
has  completed. 

28  (s)  :  Same  as  27 . 

30  (s) ;  Memory  requests  are  user  generated* 

32 (s) ;  Dynamic  memory  allocation  takes  place  through 
the  supervisor  process. 

55 (s) :  JCL  facility  specifies  the  resources  required 
of  a  job-  to  the  supervisor  process. 

-60(c):  The  user  cannot  dynamically  allocate  memory. 


6.4  .(sj:  The  user  is  restricted  in  the  number  of  I/O 
devices  he  may  request. 

9:  .System- resources  must  be  allocated  to  a  job,  prior  to 

the  job  being  made  eligible  to  run. 

10: (c) :  There  are;  user  resources;  i.e. ,  the  processor, 
which  are.  allocated  at  the  process  level. 

27 :  (s) :  The  same  process  reclaims  resources  upon 
completion-.. 

28 ;  (s) :  Same  as  27. 

30:  (sj:  Memory  allocation  must  fail  within  this  require¬ 
ment. 

36:  (s):  Device  handler  routine  is  started  for  each  job 
-at  this.  -time. 

55:  (s) :  JCL  facility  identifies  resources  required  of  a 
job. 

10:  A  process  must  be  ready  to  run  prior  to  being  allocated 

a  processor. 

13:  (s) :  A  process's  status  is  maintained  in  an  informa¬ 
tion  table  (PCB)i 

19: (c):  Initially  the  user's  job  is  a  process. 

20 Ms)  :  The  traffic  controller  may  select  a  ready  process 
only. 

23 (s):  Ready  processes  must  be  chained  into  a  list  of 
eligible  processes. 

25 (c) :  A  process  is  not  ready  if  blocked. 


11:  User  communication  with  the.  operating  system  is  via  SVC 

instruction*. 

15 :  (c ) :  Only  certain  SVC  instructions  are  user  callable. 

26  (s) :  A  process  relinquishes  control  via  SVC 
instruction. 

46  (s)  :  A  request  to  send  a  message  is.  via-  SVC 
instruction. 

49  (s)  :  A  request  to  read  a  message  is  via  SVC 
instruction. 

53  (s):  Dynamic  process  creation/destruction  is  via  SVC 
instruction . 

63  (s):  A  process  can  signal  job  completion  via  SVC 
instruction. 

12;  The  operating  system  must  protect  user  jobs  from  each 

other. 

13:  (s) :  Information  tables  contain  information  on  jobs, 
processes  and  resources. 

18  (s):  Supervisor  routine  creates  a  separate  environ¬ 
ment  for  each  job  and  essentially  isolates  it 
from  other  jobs. 

34  (s) :  Memory  is  also  required  to  be  protected  from 
simultaneous  user  jobs. 

36  (s):  The  device  management  routine  runs  as  a  separate 
process,  one  per  device  to  isolate  jobs. 


37  (c);.  The- device  handler  routines  deal  with  many  jobs 
and  must  isolate  each  one. 

43  (s)  :  The  P-V  operations  serve  as  a:  locking,  function 
and  help  to  insure  verifiable  access  rights. 

59 (s);  Dynamically  created  process  must  remain  within 
their  process  -group. 

13:  Operating  system  must  utilize  information  table  to 

monitor  and  control  processing. 

14 (s) ;  Dynamic  allocation  of  system  tables  is  required 
for  multi-programming  environment. 

23 (s) :  Round-robin  scheduling  is  most  effectively 
accomplished  by  chaining  PCB ' s . 

30  (s);  Memory  allocation  requires  adjustment  to  .inf or*? 
mation  tables . 

32  (s)  ;  Dynamic,  allocation  of  memory  by  the  operating 
system  is  used  for  tables. 

j 

35  (s);  Free  storage  blocks  must  be  updated  each  time 
memory  is  freed. 

36:  (s):  Unit  control  blocks  are  built  and  maintained  by 
the  operating  system. 

43:  (s) :  p-v  operations  are  used  extensively  to  update 
semaphores  and  lock  resources. 

46 :  (s ) :  The  message  facility  is  a  buffered  table  which 
is  used  to  pass  information  between  processes. 
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14:  System  tables  can  be  dynamically  allocated'  and  released. 

32  (s)'s  Dynamic  memory  allocation  fully  supports  this 
requirement. 

51  (s):  The  queuing  of  messages  requires  a  dynamic 
allocation  facility. 

60 (c)  :  The  user  is  strictly  prohibited  from  dynamic 
allocation. 

15:-  Certain  extended  machine  constructions  are  user  callable. 

26 (s) :  The  process  may  issue  a p  SVC  instruction  to  stop 
itself. 

47 (s) :  Message  facility  is  implemented  with  user 
ailable  SVC’s. 

58 (s) :  Dynamic  process  creation  is  implemented  with 
■user  callable  SVC’s. 

63 (s):  User  signals  completion  via  an  SVC  instruction. 

16:  System  process  routine  an  re-entrant  and  shared. 

21 (s):  Job  scheduling  is  a  system  process  which  must  be 
shared,. 

'32: (s):  The  operating  system  maintains  pure  code  by 
dynamically  allocating  memory  for  work  space, 
for  system  routines. 

36 (s)  :  The  device  management  process  is  a  system  process 
which  must  be  shared. 

61(c):  User  processes  cannot  destroy  system  processes. 
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17:  Extended  machine  instructions  are;  executed-  in  the 

supervisor  state. 

44  ( s ) :  The  interrupt  handler  must  be  provided  to  service: 
an  SVC  interrupt. 

18:  The  supervisor  process  must  create  and  delete  the 

environment  in  which  a  job  runs.' 

19:  (s):  The  supervisor  initially  creates  one  process  per 
job. 

27:  (s):  This  requirement  deals  with  the  destruction  of 
processes. 

28  (s)  :  Same  as  27. 

58  (s) :  User  creation  of  processes  supplements  the  job 
environment. 

61(c) :  The  user  cannot  destroy  the  entire  job 
environment . 

19:  Initially  one  process  is  created  for  each  user's  job. 

58  (s)'-:  The  user  process  may  create  additional  processes 
-to  create  a  process  group. 

20:  Jobs  are  scheduled  strictly  oh  a  first  come,  first 

served  basis. 

2!(s):  FCFS  scheduling  is  simplistic?  therefore,  we  can 
improve  system  performance  at  some  later  time 
if  this  is  strictly  modularized. 

39  (s):  The  fact  that  all  input  devices  are  dedicated 
forces  us  to  use  an  FCFS  algorithm. 


.21:  The  job  scheduling  function  must  be  modularized  so  that 
improvements  to  the  system  can  be  easily  accomplished. 
37  (s) :  In  order  to  improve  the  sophistication  of  the 
job  scheduler,,  it  would  be  necessary  to'  inter¬ 
face  to  a  great  extent  with  the  device  handler 
routine . 

39  (s)  :  Again  for  the  same  reason,  improvements  to  the 
job  scheduler  are  accomplished  in  conjunction 
with  input  stream  handler. 

55  (s):  JCL  would  be  affected  by  improvements  to  the 
job>  scheduler. 

22:  The  process  scheduler  (traffic  controller)  must  time- 
slice  CPU  usage  to  achieve  multi -programming. 

24  (s):  Timer  runout  trap  is  the  result  of  CPU  usage 
being  exceeded. 

25(c):  A  process  may  terminate  while  awaiting 
synchronization . 

26  (c) :  A  process  may  terminate  voluntarily  . 

44  (s) :  The  interrupt  handler  processes  a  timer  runout 
and  returns  control  to  the  traffic  controller. 

23:  Ready  processes  are  scheduled  in  simple  round-robin 
fashion  by  the  traffic  controller. 

44  (s):  The  interrupt  handler  gives  control  to  the 

traffic  controller  in  order  to  dispatch  another 


process. 


58(c),: 
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Sin'ce^  processes  are  scheduled  in  this  fashion 
a  user  may  desire  to  create  more  processes  in 
order  to  grab  ,a  larger  time  quantum. 

63 (s) :  User  signals  completion  so  that  the  next  process 
may  start  up. 

24:  A  process  shall  be  blocked,  and  control,  released  to  the 
traffic  controller,  when,  a  timer  runout  trap  is  deleted. 
44(s) :  The  interrupt  handler  is  the  means  by  which  the 
traffic  controller  regains  control. 

25:  A  process  shall  be  blocked  and  control  passed  to  the 
traffic  controller  when  the  process  must  wait  for 
synchronization  with  another  process. 

29  (s)  :  Processes  must  be  uniquely  identifiable  in  order 
to  synchronize. 

43 (s) :  P-V  operations  are  used  system-wide  for  synchro¬ 
nization/  but  this  is  directed  towards 
synchronization  of  system  processes. 

46  (s):  User  synchronization  can  be  accomplished  via  the 

message  facility. 

47  (s):  Message  facility  is  available  to  users. 

54  (s) :  A  process,  expecting  a  synchronizing  message,  is 
blocked  until  it  receives  one. 

26:  A  process  is  blocked  when  it  relinquishes  control  to  the 
traffic  controller. 


63 (s):  The  user  must  relinquish  control  by  a  specific 
signal  to  the  operating  system. 

27:  The  supervisor  routine  must  reclaim  all  system  resources 
for  a  job  when  the  job  .has  completed. 

28(c):  The  supervisor  must  also  reclaim  resources  if  a 
user  commits  an  error. 

35  (s).:  .When  memory  is  freed  by  direction  of  the 

supervisor  it  must  also  re-configure,. 

36  (s) :  The  device  handler  routine  is  a  resource  that 

must  be  reclaimed. 

38  (s):  The  devices  used  must  be  released. 

44  (s):  A  program  interrupt  starts  things  happening. 
61(c):  The  supervisor  routine  must  destroy  all  system 
processes  for  a  job  which  terminates. 

63  (s):  The  user  must  signal  completion. 

28:  The  supervisor  process  must  reclaim  all  system  resources 
when  an  error  condition  abnormally  terminates  a  job. 

35:  (s) :  Memory  is  re-configured  when  it  is  reclaimed. 

36:  (s):  The  device  management  routine  must  be  reclaimed. 
38  (s):  Devices  resources  must  be  reclaimed  at  this 
time. 

44  (s):  The  interrupt  handler  signals  that  an  error  has 
occurred . 

61(c):  The  supervisor  must  destroy  all  system  processes 
for  a  terminated  job. 
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29:  Reference  to  processes  within  a  process  group  is  by 
symbolic  name. 

48  (s  j :  The  sending  process  must  have  a  name. 

49 (s):  The  receiving  process  must  have  a  name  for  the 
message  facility  to  operate., 

58*(s )y  A  process  is  given  a  name  at  creation  time. 

59  (s).:  Names  are  unique  with  a  partition. 


30:  The,  operating  system  must  allocate  memory  for  job. 

partitions,  the  size  of  which  is  specified  by  the  user. 

31(c):  Memory  allocation  is  limited  to  increments' of 
2K  blocks. 

32(c):  Memory  may  also  be  allocated  by  the  system. 

33 (sj :  A  list  of  free  areas  is  updated  each  tine  a 
partition  is  freed. 

55 (s):  A  simplified  JCL  is  available  for  the  user  to 
specify  his  memory  requirements. 

59(c):  Memory  partition  requested  must  be  large  enough 
for  all  dynamically  created  processed. 

60(c):  The  user  cannot  dynamically,  allocate  memory. 


31:,  Memory  is  allocated  to  a  job  in  contiguous  2K  blocks. 
32(c):.  The  operating  system  does  not  need  memory 

allocated  on.  2k  blocks  since  it  has  its  own 
protection  scheme. 

Best-Fit  algor ithm  memorizes  partition  waste. 
Allocation  in  2K  blocks  allows  hardware 
protection  by  the  IBM  360  system. 


33 (s) : 
34  (s)  : 


35 (s)  :  Memory  is  re-configured  whenever  it  is.  freed. 

43  (s)..:  P-V  operations  can  serve  as.  a  lock  on  a  database 

55 (s } :  The  user  specifies  memory  requirements  using  JCL 

32:  Operating  system  may  dynamically  allocate  memory  to 

itself  for  system  processes. 

34:(s) :  System  workspaces  must  be  protected  the  same  as 
user  work  spaces. 

35 (si:  Free  areas  are  collapsed  for  system  processes. 

36 (s):  Device  management  system  requires  memory  for  its 
own  tables. 

51 (s):  Message  queuing  facility  requires  memory. 

60 (c) :  The  user  cannot  dynamically  allocate  memory. 

33:  Memory  is  allocated  using  a  best-fit  algorithm. 

35 (s):  Memory  is  reconfigured  when  deallocated  to 

insure  that  the  largest  contiguous  blocks  are 
available. 

55 (s):  User  must  specify  memory  requirements  on  JCL. 

34:  Memory  must  be  protected  to  prevent  the  simultaneous 

allocation  of  a  partition  to  multiple  jobs. 

43: (s) :  The  P-V  operation  is  used  extensively  as  a 
lock  on  a  database. 

44: (s):  The  interrupt  handler  is  provided  as  a  means 
of  detecting  out-of-bounds  memory  requests. 

59 (s):  Dynamically  created  processes  must  run  in  the 
partition  of  the  parent  job  which  further 


protects  memory.,, 

6  (Ms)  :  The  user  is  prevented  from  allocating  additional 
memory. 

35:  Free  storage  areas  are  collapsed  into  contiguous  blocks 

of  memory  whenever  a  partition  is  freed. 

63:  (s):  The  user  must  signal  completion  to  the  operating 
.system  so  that  partition  can  be  freed. 

36:  Operating  system  must  supply  a  device  management  system, 

which;  runs  as  a,  separate  process,  one  per  device. 

37  (s)  :  Device  handler  must  be  included  within  device, 
management  system., 

38 (s):  Since  devices  are  dedicated,  only  one  process 
per  device  is  required. 

39 (s);  These  constitute  the  specific  requirements  of 
the  device  handler  routine. 

40 (s):  Same  as  above. 

41(s) :  Since  I/O  devices  operate  via  multiplexor 
channel  there  is  not  need  for  I/O  traffic 
controller. 

42 (s):  Device  management  system  must  enable  the  user 
to  supply  his  own  handling  routines. 

43 (s):  P-V  operation  is  used  to  lock  devices. 

44 (s):  P-V  plus  limited  interrupt  facility  provide  I/O 


interface . 


o 
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37:  Device  handler  routines  mush  support,  multiple  job 
streams  from  card  readers . 

38 (s):  Dedicated  devices  enable  sequential  processing 
and  simplify  designation  of  job,  streams. 

39  (s),.:  A  card  reader  represents  an  input  stream;  hence, 
multiple  card  readers  represent  multiple  job 
streams . 

41 (s);  Multiplexed  channels  enable  simultaneous  servicing 
of  multiple’  devices. 

43  (s);:  P.-V  operations,  are  used  to  lock  devices. 

56: (s) :  The  device  handler  must  be  able  to  distinguish 
among  user  decks  and  data  cards. 

(  y  38:  All  devices  are  dedicated. 

39: (s)  :  Since  devices  are  dedicated,  a  card  reader 

represents  an  input  stream. 

40 (s):  Since  devices  are  dedicated,  a.  line  printer 

» 

represents;  an  output  stream. 

41 (s):  Multiplexed  channel  is  used  for  dedicated 
service. 

42(c):  Non-standard  devices  may  not  necessarily  be 
dedicated . 

43 (s):  P-V  operations -are  used  to  lock  devices. 

64  (s):  User  must  specify  which  devices  are  being  used 
by  his  program. 

y  ,  39:  The  device  handler  routine  supports  one  card  reader  per 

input  stream. 
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40  (c) :  The  output  stream  conversely  supports  one 
line  printer. 

41,(s)  :  Multiplexing  eliminates  the  need  for  an  I/O 
traffic'  controller. 

42(c):  A  user  may  specify  his  own  routine. 

64 (s) :  The  user  must  designate  the  card  reader  to  be 
used.  o 

40:  Device  handler  must  support  one  line  printer  per  output 

stream. 

41 (s):  Multiplexing  eliminates  the  need  for  an  I/O 
traffic  controller. 

42 (s):  A  user  can  supply  his  own  routines. 

64  (s):  The  user  must  specify  the  line  printer  to  be 
used. 

\ 

41:  Input/output  devices  operate  via  multiplexor  channel. 

42(c):  The  user  may  provide  his  own  routines  and  I/O 
interface. 

43  (s)  :  The  P-V  operation  can  be  used  to  lock  a  device. 

56  (sj:  Input  data  for  a  user's  program  must  be  accepted 
via  multiplex  or  channel. 

42:  The  user  can  provide  his  own  routine  for  non-standard 

devices. 

64:  The  user  must  specify  the  use  of  an  exceptional 

device  to  the  system  via  JCL; 
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43:  A  process  synchronization  mechanism  must  be  provided. 

45  (s)-:  The  synchronization  mechanism-  is  used  as  the: 

basis  for  process  support  and,  therefore,  is 
not  available  to  users. 

44:  .An  interrupt  handler  must  be  provided. 

63  (s)  :  A  user  signals  completion1  via  SVC  interrupt. 

46r  A  message  facility  must  be  provided  for  user  processes. 
47:  (s):  The' message  facility  is  available  to  all 
processes. 

48:  ( s )• :  Requirements  for  sending  a  message. 

49:  (s)  :  Requirements  for  receiving  a  message. 

'50:  (s):  This  contains  the  message  length  requirement. 

51: (s) :  Messages  may  be  queued  in  order  to  be  read  by  a 
process. 

52:  (s):  Messages  are  released  when  a  process  terminates. 
53:  (s) :  The  message  facility  has  no  receipt  mechanism. 

'54:  (s):  Messages  can  be  used  for  process  synchronization. 

48:  The  name  of  the  sending  process  must  be  prefixed  to  a 
message. 

49  (s):  The  receiving  message  must  be  able  to  read  from 
,  ‘whom  the  message  came. 

53  (s) :  The  message  facility  does  not  receipt  for 

message  transfer. 

54  (s):  The  message  facility  can  be  used  for  one-to-one 

process  synchronization. 


49:  The  -receiving  process  must  read  the  name  and  text  from 
the  originator. 

51(c)  :  The  queuing’  process  makes  it  essential  that 
the  message  receiver  be  able  to  tell  from 
whence  the  message  came., 

53(c):  Messages  are  hot  receipted  for., 

54(c):  A  process  awaiting  synchronization  must  be  able 
to  determine  that  the  message  is  from  the 
proper  source. 

50::  Messages  are  of  an  arbitrary,  yet  specified  length. 

51,(s)  :  Since  messages  may  vary  in  length,  queuing  them 
is  the  most  simplistic  means  of  dealing  with 
the  variable  length. 

52:  All  messages  are  released  when  a  process  terminates. 

53  (s) :  The  sending  process  may  have  been  terminated 
before  the  receiving  process  read  the  message. 

55:  User  programs  utilize  a  simplified’ job  control  language. 
60:  (s):  User  is  limited  to  the  amount  of  memory 
specified  in  his  JCL. 

64  (s):  The  user  must  specify  his  input/output  device 
requirements  utilizing  JCL  statements. 

56:  The  operating  system  must  accept  input  data  from  the 
user's  job  stream. 


65:  (s) :  The  supervisor  process,  controls  the  loading  of 
the  user's  deck  into  the  machine. 

57s  The-  supervisor  process  must  load  the  user-supplied 
object  deck  into  the  user  partition. 

60:  (s) :  Once  the  user's  deck  is  loaded/  he;  is  stuck 
with  whatever  memory  partition  he  requested. 

65:  (s) :  The  supervisor  process  handles  the  loading 
function. 

.58 :  The-  user  process  may  dynamically  create  and  destroy 
additional  processes. 

59  (s)  :  Dynamically  created  processes  are  limited  to 
the  user's  partition. 

60(c):  The  user  cannot  destroy  system  processes. 

61  (s):  User-created  processes  are  limited  to  problem 
state. 

59:  Dynamically  created  processes  run  in  the  same  partition 
as  the  parent-  job. 

60:(sj'j  The  user  process  cannot  create  processes  which 
also  expand  its  memory  requirements; 

62:  (s) :  User  processes  all  run  to  problem  state. 

61:  User  processes  cannot  destroy  system  processes  within 
the  same  process  group. 

62:  (s) :  Since  all  user  processes  run  in  the  problem 

state,  and  system  processes  in  the  supervisor 
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state we  are  -protected-. 

6 3  s'  The  ^user  process  must  signal  completion  :of  the  process, 
to  the  operating  system.. 

65:  The  supervisor  process  now  takes  over  to  re¬ 

claim  resources  or  to  signal  the  traffic 
controller. 
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36  ? 

38? 

44? 

61? 

63? 

28 

< 

9) 

8? 

9? 

18? 

27? 

35? 

36  ? 

33? 

44? 

61  ? 

29 

( 

6) 

6? 

25? 

48? 

49? 

58? 

59? 

30 

< 

9). 

3 1 

9? 

13? 

31? 

32? 

33? 

55  ? 

59? 

60? 

31 

( 

7) 

30? 

32? 

33? 

;.34  ? 

35? 

43? 

55  ? 

32. 

( 

11) 

S? 

13? 

14? 

16  ? 

30? 

31? 

34? 

35  ? 

36? 

51  ? 

60  ? 

33 

< 

4) 

30? 

31? 

35? 

55  ? 

34 

9) 

5? 

12? 

31? 

32? 

43? 

44? 

59? 

60? 

62? 

35 

< 

7) 

13? 

27? 

28? 

31? 

32? 

33? 

63  ? 

36 

< 

15) 

9? 

12  ? 

13? 

16? 

27? 

28? 

32? 

37? 

38? 

39? 

40? 

41? 

42? 

43? 

44? 

37 

( 

9) 

5? 

12? 

21? 

36? 

38? 

39? 

41? 

43? 

56? 

38- 

< 

10) 

27? 

28? 

36? 

37? 

39? 

40? 

41  ? 

42? 

43? 

64? 

39 

( 

9) 

20? 

21? 

36? 

37? 

38  ? 

40? 

41? 

42? 

64  ? 

40 

( 

6) 

36  ? 

38? 

39? 

41? 

42? 

64  ? 

41 

( 

8) 

36? 

37? 

33? 

39? 

40? 

42? 

43  ? 

56  ? 

42 

< 

6) 

36  ? 

38  ? 

39? 

40? 

41? 

64  ? 

43 

( 

12) 

5? 

6  ? 

12? 

13? 

25? 

31? 

34? 

36  ? 

37? 

38? 

41? 

45? 

44 

( 

9) 

17? 

oo , 

Am  Am  7 

2o  ? 

24? 

27? 

28? 

34  7 

36? 

63  ? 

45 

< 

1 ) 

43  ? 

46 

< 

12) 

6  ? 

1  1  V 

13? 

25? 

47? 

48? 

49  ? 

50? 

51? 

52? 

33 ?  54 ? 


47 

(, 

4) 

:6  r 

15?. 

25? 

48 

( 

5;j 

29? 

46? 

49? 

49 

(' 

7) 

11? 

29? 

46  ? 

50 

.( 

2) 

46  ? 

51;? 

Si- 

C 

5) 

14? 

3?,? 

46? 

52 

( 

2) 

46  ? 

53? 

33 

( 

4) 

46? 

48? 

49? 

54 

( 

5) 

10? 

25? 

46? 

■55 

( 

9) 

5? 

8  ? 

9? 

56 

i 

3 ) 

37? 

41? 

65? 

57 

< 

2) 

60? 

65? 

53 

( 

10) 

6? 

,1  i  ? 

15? 

59 

( 

7) 

12? 

29? 

30? 

60 

< 

9) 

8? 

14? 

30? 

61 

( 

6  )' 

•16  ? 

18  ?- 

27? 

62 

< 

4) 

7? 

34? 

59? 

63 

( 

3) 

11? 

15? 

23? 

64 

( 

6) 

8? 

38? 

39? 

65 

< 

4) 

5? 

56? 

57? 

(AVERAGE  NO*  OF  LINKS  PER 


192  - 

4o.  ' 

53 ?  54? 

48?  517  53?  54? 

49?  50? 

52? 

48?  49? 

21?  30?  31?  33?-  60?  64? 


IS?  19 ?  23?  29?  59?  60?  61? 
3.4?'  58?  60?  62? 

32?  34?  55?  57?  58?  59? 

28?  58?  62? 

61  ? 

26?  27?  35?  44?  65? 

40?  42?  55? 

63?  ’ 

NODE:  6.053). 


req: 

I  SOL 


ISOLATED 

1 

4 


nodes: 


4 

66, 

67 

63 

69 


red: 

DENG 

♦ 

/I  ?2?-3?4?66?67?68?69/ 

THE  FOLLOWING  NODES  HAVE’  BEEN  REMOVED.* 

1  2"  3  4  6.6  67  68  69 


ENTER  FILE  NAME! 
S0SA12 


STATUS  SAVED  IN  FILE  S0SA12 


REG! 

mm 

.<■  PRECLUSTERING  COMPLETE ) 


;P, RECLUSTERING  PERFORMED  AND  DISTANCE  MATRIX  COMPUTED  WITH  f 
CLUSTERS  NOT  TAKEN  AS  SINGLE  NODES, 

REG! 

PRCL 


•CLUSTER  :-NO)  OBJECTS 


1 

•S' 

1) 

i 

'3 

> 

1) 

o 

Am 

3 

i> 

3 

4 

-< 

1) 

4 

5 

< 

1) 

5 

6 

( 

1) 

6 

/ 

< 

1) 

7 

8 

( 

1) 

8 

9 

< 

1) 

9 

10 

< 

t; 

10 

11 

< 

1) 

IT 

12 

( 

l) 

12 

13 

< 

l) 

13 

14 

1  ^ 

( 

t 

1) 

1  \ 

14 

* i  cr 

21 

< 

1) 

21 

O'? 

W  Am 

< 

1) 

O'? 

Am  Am 

23 

< 

1) 

23 

24 

< 

1) 

24 

25 

< 

1) 

25 

26 

1) 

26 

27 

< 

T) 

27 

28 

< 

1) 

28 

29 

< 

1) 

29 

30 

( 

1) 

30 

31 

( 

1) 

31 

32 

( 

1) 

32 

33 

< 

1) 

33 

34 

( 

1) 

34 

35 

< 

1) 

35 

40 
4  T 

42 

43 

44 

45 

46 

47 

48 
49, 

50 

51 

52 

53 
54- 


< 

1) 

41 

( 

1) 

42 

( 

1) 

43 

< 

1) 

44 

( 

i-y 

45 

< 

U 

46 

( 

i) 

47 

< 

i) 

48 

( 

i) 

49 

< 

i) 

50 

< 

i) 

51 

< 

i-> 

52 

< 

i) 

53 

( 

i) 

54 

( 

i) 

55 

( 

i) 

56 

JvJ 


-  195  - 

REG  J 
DIMN 

(PRECLUSTER INS  COMPLETE) 

F'.RECLUSf  ERINS  PERFORMED  AND  DISTANCE  MATRIX  COMPUTED  WITH  P 
CLUSTERS  NOT  TAKEN  AS,  SINGLE  NODES. 

REG  5 
SIMA 

SIMILARITY  MATRIX  COMPUTED. 

REG 

INPA 

.ENTER'  PERCENTAGE  PARAMETER  t 
>80  ♦ 

INITIAL  PARTITION  COMPUTED  WITH  P  =  80.00  %♦ 

REG. 

HCMl 

BEST  PARTITION  MEASURE.  0.556 
DO  YOU  WANT  TO  PRINT  THE  TREE? 

NO 

REG? 

•PRGL 

CLUSTER  (MO)  OBJECTS 


1 

(IS) 

l 

4 

5 

9 

10 

26 

27 

28 

29 

30 

31 

51 

55 

.56 

58 

2 

(13) 

o 

*m  . 

3 

6 

7 

11 

13 

15 

19 

21 

99 

43 

54 

59 

3 

(IS) 

,8 

12 

16 

17 

32 

33 

34 

35 

36 

38 

37 

39 

41 

52 

60 

4 

(  7) 

14 

13 

20 

23 

24 

40 

57 

5 

ai> 

25 

42 

44 

45 

46 

47 

48 

49 

50 

53 

61 


r  196 

REG? 

HCM2 

BEST  'PARTITION  MEASURE?  0.577 
-66/  YOU  WANT  TO  {PRINT  THE  TREE? 

no 

RECK 

PRCL 

CLUSTER  (NO)  OBJECTS 


i 

(14) 

1 

8 

12 

16 

17 

32 

33 

34 

35 

36 

38 

37 

39 

60 

/y 

tm- 

(14) 

> 

tm 

6 

7 

11 

15 

18 

19 

20 

21 

99 
&•  a 

40 

43 

54 

.59 

3 

(  2) 

3 

1.3 

4 

(14) 

4 

5 

9 

10 

26 

27 

28 

29 

30 

31 

51 

•55 

56 

58 

fi 

(  4) 

14 

23 

24- 

57 

6 

<  9.) 

25. 

42 

44 

45 

46 

47 

48 

49 

50 

7 

(  1) 

41 

8 

(  3") 

'52' 

53 

61 

REG  ? 

BIMN 

(PRECLUSTERING  COMPLETE) 

PRECLUSTERING  PERFORMED  AND  DISTANCE  MATRIX  COMPUTED  WITH  P  =  1 t 
CLUSTERS  NOT  TAKEN  AS  SINGLE  NODES. 

RECK 

■HCM3 

BEST  PARTITION  MEASURE?  1.119 
DO  YOU  WANT  TO  PRINT  THE.  TREE? 

HO 


CLUSTER  (NO).  OBJECTS 


1 

(11) 

1 

8 

12 

16 

17 

33 

39 

41 

52 

53 

61 

9 

Xm 

(17) 

2 

3 

6 

7 

11 

13 

15 

18 

19 

20 

21 

99 

■W 

,25. 

40 

43 

54 

59 

3 

(16) 

4 

5 

9 

10 

26 

27' 

28 

29 

30 

31 

46 

47 

51 

55 

56 

'58 

4 

(  4) 

14 

23 

24 

57 

5 

(  7) 

32 

34 

35 

36 

38 

37 

60 

6 

(  6; 

42 

44 

45 

48 

49 

50 

-  197  r 


REQ;J 


•BEST  PARTITION  MEASURE  ? 

DO  YOU  WANT  TO  PRINT  THE 
YES. 

SET  PAPER  AND  PRESS.  RETURN,?. 


1.119 

TREE? 


0~K 

4Lm  W 

24 

14 

57 

53 

61 

52 

16 

17 

12 

1 

33 

39 

8 

41 

26 

51 

4 

5 
27 

29 
31 

55 

56 

30 
,53 

46 

47 
10 
23 

9 


T  I 


~ 


*  i  - 
•* 


I 


I  “ 
•* 


■  i  ■ 
■# 


, - * 


•* 


■# 


I 

-* 


•* 


I 

I  . 
I 

•# 


1'9'8* 


(4 c 


35 

XX) 

34 

37 

32 

60 

43? 

49 

44 

45 

42 

50 
r> 

lit 

21 

43 
6 

19 
15 
54 
25 
18 

20 
40 
59 

7 

11 

3 


I? 

-#•  !.- 


-* 

!« 

i 


•y 


*y 


-* 


•y 


i  * 
■# 


** 


-* 


■X 


13  - - - * 

COLLAPSED  OBJECTS* 
OK  !*){.  36  38 


MEASURES} 


-193*500 

-187.500 

•  -153.917 

-153*917 

-120.250 

-112*500 

-88.217 

-82*800 

-61*361 

-56*278 

-32*875 

-31.591 

-13.224 

-16.012 

-7*174 

-5*805 

-0.343 

0*160 

0*979 

1*051 

-180*167 

-173.667 

-145*917 

-133*917 

-109.000 

-102.750 

-80.050 

-77*717 

-51*236 

-45.653 

-26*306 

-23.694 

-12*858 

-10,633 

-3*277 

-2*350 

0*484 

0,779 

0,742 

0,240 

-168*167 

-165,667 

-133,750 

-123,500 

-96,250 

-93.050 

-70*500 

-66.333 

-40*528 

-37,375 

-21,278 

-20,155 

-8,539 

-7,770 

-1*722 

-1,070 

0,911 

1*119 

0,081 

( 


»<• 


I 


§ 


-  199.  ^  • 


REQJ 
'  PRCti 

CLUSTER:  (NO)  OBJECTS 


1 

(11) 

i 

B 

12 

16 

17 

33 

39 

41 

52 

53 

61 

9 

Am 

<  17) 

‘2 

3 

6 

7 

11 

13 

15 

is 

19 

20 

2? 

oo 

,Am  Am 

25 

40 

43 

54 

59 

3 

(16 ) 

4 

5 

9 

10 

26 

,27 

28 

29 

30 

31 

46 

47 

51 

55 

56 

58 

4 

(  4) 

14 

23 

24 

57 

5 

(  7) 

32 

34 

35 

36 

38 

37 

60 

6 

(  6) 

42 

44 

45 

48 

49 

50 

REQJ 

EVAL 

STRENGTHJ  1  *  98?j64  ? 
COUPLING*  0*8 674f 
MEASURE:  1.119. 


REG) : 

BE  NO 

5  " 

/2»-3>4»7ril»i3»iS»i.8»19»20»2i»22f2S»^0»43»S4»5?»4f5»?»10r26F27»28» 

♦ 

29r30?31y46>47F51»55F56F58Fl4F23r24F57f32»34F35F36»38>37>60?42!>44» 

♦ 

♦ 

45 >48 >49 >50/ 


THE  FOLLOWING  NODES  HAVE  BEEN  REMOVED: 


9 

Am 

3 

4 

5 

6 

7 

9 

10 

11 

13 

14 

15 

18 

19 

20 

21 

99 

Am  Am. 

23 

24 

25 

26 

27 

28 

09 

30 

31 

32 

34 

35 

36 

37 

38 

40 

42 

43 

44 

45 

46 

47 

48 

49 

50 

31 

54 

55 

56 

57 

58 

59 

60 

NODES  HAVE  BEEN  RENAMED  AS  FOLLOWS: 
OLD  NO.  NEW  MO. 


1 

9 

«• 

3 

4 

5 

6 

7 

8 
9 

10 

11 


1 

8 

12 

16 

17 

33 

39 

41 

“52 

53 

61 


4s 


•> 


f 


Reg; 

DiMN 

<  PRECLUSTERING  COMPLETE) 

NO  PRECLUSTERING  PERFORMED*  DISTANCE  MATRIX  COMPUTED  WITH  P 

REG  { 

SIMA 

SIMILARITY  'MATRIX  COMPUTED* 

REG  ♦ 

INFA 

ENTER  PERCENTAGE  PARAMETER,* 

80, 

INITIAL  PARTITION  COMPUTED  WITH  P  -  80,00  %, 

reg; 

HCM3 

BEST  PARTITION  MEASURE;  0.091 
DO  YOU  WANT  TO  PRINT  THE  TREE? 

NO 

reg; 

PRCL 

CLUSTER  <N0)  OBJECTS 


1  <il)  1  2  3  A  5  6  7  8  9  10 

11 

reg; 

EVAL 

STRENGTH;  0,0909* 

coupling;  o.oooo * 
measure;  0,091. 


-  2.01  - 


reg: 

REST 

ENTER  FILE  NAME  : 
SOSA12. 


ADJACENCY  MATRIX  READ  FROM  FILE  SOSA 12 


RECK 

DENG 

* 

♦ 


Alt  8 j 12 
♦ 

tX6tl 

,7  >3  3t 

3  9t 

41 »52> 

5.3>61>4>5> 

9t  10 1 

26  >  27> 

28  >29  > 30  >  31 >  46  >47* 

51>55>56r58> 

1 4  r.23 

r.  24 

»57f 32 

1 34  »35;»36 1 

38  >37 

>60*42 

:>  44  >45  >48  >49  >50/ 

THE  FOLLOWING  NODES 

HAVE 

BEEN 

removed: 

1 

4 

5 

8 

9 

10 

12 

14 

16 

17 

23 

24 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

41 

42 

44 

45 

46 

47 

48. 

49 

so 

51 

52 

53 

35 

56 

37 

38 

60 

61 

NODES  HAVE  BEEN  RENAMED  AS  FOLLOWS* 


OLD  NO. 

NEW  1 

r> 

*• 

,1 

“V 

o 

2 

6 

3 

7 

4 

11 

3 

13 

6 

15 

.7 

18 

8 

19 

9 

20 

10 

21 

ii 

r>o 

*• 

12 

*-  w 

13 

40 

14 

43 

IS 

.54 

16 

?REG.J 

•DIMN 

< PRECLUSTERING  COMPLETE) 

* 

NO  PRECLUSTER I NG  PERFORMED i  DISTANCE  MATRIX  COMPUTED  WITH  P  = 

REQJ 

SIMA 


SIMILARITY  MATRIX  COMPUTED* 

REQJ 
INF' A 

ENTER  PERCENTAGE  PARAMETER** 

80* 

INITIAL  PARTITION  COMPUTED  WITH  P  =  80*00 


REQJ 

HCM3 

PEST  PARTITION  MEASURE;  0*448 
DO  YOU  WANT  TO  PRINT  THE  TREE? 

NO 

REQJ 
PR  CL 

CLUSTER  <N0)  OSUECTS 


V  <  8)  1  3  7  -9  11  13  15  16 

2  (  6)  2  4  5  6  12  17 

3  •<  3)  8  i'O  14 

REQJ 

EMAL- 


STRENGTH*  0*8357> 
COUPLING';  0 ♦ 4375  r 
MEASURE?  0.448* 


ADJACENCY  -MATRIX  READ  FROM  FILE  S0SA12 


%'  REQ } 

1<  DENO 

V' ' 

* 

r  .  /I  f8»  12»16rl7>33»39  i>4l  »52»  53r  61  r.2r3»6r7 1 11 j>  13 rlS?  18rl9i»2Q  r  2i,r“22i’25.i’ 

r*  ♦  '  1  '  '  ' 

♦ 

L  40>43>54>59;>14>23>24>57>32>34>35r36*38»37>60r42r44>45f48*49>5d/ 


f  _ 

0 

THE  FOLLOWING 

NODES 

HAME 

BEEN 

REMOVED. 

i 

£ 

£,*  , 

1 

o 

Am 

3 

6 

7 

8 

11 

12 

13 

14 

\ 

,  0$ 

i%r  - 

115: 

16 

17 

18 

19 

20 

21 

oo 

A*.  Am 

23 

24 

X 

¥: 

--  .25 

32 

33 

34 

35 

36 

37 

33’ 

39 

40 

\ 

'  *• 

41 

42 

43 

44 

45 

48 

49 

50 

52 

53- 

<3 

54 

57 

59 

60 

-61 

r> 

NODES  HAVE  BEEN  RENAMED-  AS  FOLLOWS* 
’.OLD  NO.  NEW  NO. 


1 

n 


6 

7 

8- 

9 

10 

il. 

■12 

13- 

1\ 

15 

16 


'? 

A 


•.REG;* 

DIMM 

•CPRECLUSTERING  COMPLETE > 

NO  PRECLUSTERING  PERFORMED »  DISTANCE  MATRIX  COMPUTED  WITH  P 

REG* 

SIMA 

SIMILARITY  MATRIX  COMPUTED . 

REG* 

INPA 

ENTER  PERCENTAGE  PARAMETER.} 

SO* 

INITIAL  PARTITION  COMPUTED  WITH  P  =  80,00.  %, 

REG} 

HCM3 

BEST  PARTITION  MEASURE}  0,449 
DO  YOU  WANT  TO  PRINT  THE  TREE? 

NO 

REG! 

PRCL 

CLUSTER  <N0)  OBJECTS 


•1  <  13)  1  2  3  4,  5  6  7  8  10  11 

12  13  15 

2  (  3)  9  14  16 

REG? 

EUAL 

STRENGTH}  0,5769» 

COUPLING!  0 ♦ 1282» 

MEASURE}  0,449* 


:EST 

ENTER  FILE  NAME? 

S0SAT2 

ADJACENCY  MATRIX  READ  FROM  FILE  S0SA12 

REG* 

DEMO 

♦ 

/tf8»:i2f4A-»17r33-?,3*F41'fS2-»S3»61»3»3»4V7rlirl3,»1.5».18?l.?f^P»21?2?»'2Sr 

•4* 

40*  43  i 54*59 » 4.*5*  9  *10 * 26  *  27 »  28  *  29  *  30 *31*46*47*51  *  55  *  56 1 58  *  32 * 34 * 35  r  367  38 
377,60  i  42 * ,44  *  45  *  48 >  49  *  50/ 

THE  FOLLOWING  NODES  HAVE  BEEN  -REMOVED* 


.1 

9- 

itm. 

3 

4 

5 

.  6 

7 

8 

9 

10 

11 

12 

13 

15 

16 

17 

18 

19 

20 

21 

99 

1 M  *• 

25 

26 

27 

28 

29 

30 

31, 

32 

33 

34 

35: 

36 

37 

38 

39 

40 

41 

42- 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

S3 

54 

55 

56 

58 

59 

60- 

61 

NODES  HAVE  BEEN  RENAMED  As  FOLLOWS: 
OLD  NO*  Ni£W  NO* 


REQ :• 

DIMN 

('PRECLUSTERING  COMPLETE) 

PRECLUSTERING  PERFORMED;  AND  DISTANCE  MATRIX  COMPUTED  WITH  P 
CLUSTERS-  MOT  TAKEN  AS  SINGLE  NODES* 

req: 

SIMA 

SIMILARITY  MATRIX  COMPUTED;* 

req: 

INPA 

ENTER  PERCENTAGE  PARAMETER: 

30, 

INITIAL  PARTITION  COMPUTED  WITH  P  =  80*00  %, 

req: 

rl'CM3 

CURRENT  PRCLUSTERING  HAS  ONLY  ONE  CLUSTER.* 

UNABLE  TO  DO  IT, 


-  206  t 

REQ  i, 

;REST 

‘ENTER-  FILE  NAME* 

SGSAT2 

ADJACENCY  MATRIX  READ  FROM  PILE  SOSA 12 

REQ ' 

DENO 

♦ 

♦ 

/If  8  f  12*16 1 17  *33*39*41*52  *53*61  *  2  *  3  *  6  *  7*  1.1  *.13?  15.* 

18*19*20  *  2i  *22*25  *  4.0  *  43  *  54  *59  *  4  *  5*  9  * 

♦ 

10  *  26  *  27 » 28 *29  *  30 » 3i»  46 *  47*  51* 55  *  56  *58  r 
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APPENDIX  F 


Main  Subprobiems  Kasulting  From  The 
First  Iteration  of  The  Decomposition  Analysis 


Note:  (11)  The  number  in  parenthesis  indicates 

the  number  of  interdependicies 
identified  for  the  requirement. 
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Main  Subproblem  1;  Multi-programming  Support  Functions;:, 

5-  •  Operating  system  must  provide  a  multi— progs'^rri— 

ming  environment. 

12  (  7):  Operating  system  must  protect  user  jobs  from 
each  other. 

16  (  5) :  System  process  routines  are  re-entrant  and 
shared. 

20  (  4) :  Jobs  are  scheduled  strictly  on  a  first-come, 

first-served  basis. 

21  (  5) :  Job  scheduling  function  must  be  modularized  so 

that  improvements  to  the  system  can  be  easily 
accomplished. 

37  (  9) i  Device  handler  routines-  must,  support  multiple 
job  streams  from  card  readers. 

43  (12) ;  P-v  mechanism  must  be  provided. 

45  (  1)  :  p-v  operations  are  available  only  to  system 
processes. 

56  (  3) :  Operating  system  must  accept  input  data  from  the; 

user's  job  .stream. 

57  (  2) :  Supervisor  process  must  load  the  user's  program. 
65  (  4) :  There  exists  one  supervisor  process  per  job 

stream. 

Main  Subproblem  2:  Process  Management  Functions: 

M5  2A:  Process  Creation  and  Scheduling. 

6  (14)=:  The  operating  system  must  be  process  oriented. 
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10  {  9.) :  A  process  must  :be  ready  to  run  prior  to  being 

allocated  to  a  processor. 

19  (  5)  :  initially  one  /process  is  created  for  each 
user job. 

23  {  7},.{  Ready  processes,  are  scheduled  in  simple  round- 
robin*  fashion. 

25  (  8):  A  prpcess  shall  be  blacked’  while  awaiting 

synchronization  with  another  process. 

29  (  6) :  Reference  to  a  process  is  by  symbolic  name. 

47  (  4)<:  The  message  facility  must  be  accessible  to 

all  processes. 

58  (10) :  The  user  process  may  dynamically  create  and 
destroy  other  user  processes. 

MS  2-B  Process/Operating  System  Interface: 

7  (  4) :  The  operating  system  must  run  a  machine  that 
has  two  states. 

11  (  8) :  User  communication  with  the  operating  system 

is  via  SVC  instruction.. 

15  (  6) :  SVC  instructions  are  user  callable. 

17  (  2) :  SVC  instructions  are  executed  in  the  super¬ 

visor  state. 

26  (  6)  :  A  process  shall  be  blocked  when  it  specifi¬ 

cally  relinquishes  control  to  the  process 
scheduler. 

63  (  8) :  User  processes  must  schedule  completion. 
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MS'  2-C  Process  Time-Slicing : 

27  {  6} ;  The  traffic  controller  must  time-slice  CPU 
usage  to  achieve'  multi-programming. 

24  (  2) :  A  process  shall  be  blocked,  when  a  timer  run¬ 
out  trap  is  detected.. 

44  (10) :  An  interrupt  handler  must  be  provided. 

Main  Subproblem  3:  Resource  and  Memory  Management  Functions: 
MS  3-A  Resource  Allocation: 

8  (10) :  All  resource  requests  must  pass  through  the 

supervisor. 

9  (  8) :  System  resources  must  be  allocated  to  a  job, 

prior  to  the  job  being  made  eligible  to  run. 

13  (12) :  The  operating  system  must  utilize  information 
tables  to  monitor  and  control  processing. 

1.4  (  4)  :  System  tables  can  be -dynamically  allocated 
and  released. 

30  (  9) :  The  operating  system  must  allocate  memory  for 

job  partitions  the  size  of  which:  is 
specified  by  the  user. 

31  (7):  Memory  is  allocated  in  2K  blocks. 

32  (11) :  Operating  system  must  dynamically  allocate 

memory,  for  itself. 

33  (.  A)  :  Memory  is  allocated  using  a  best-fit  algo¬ 

rithm. 

35  (  7) :  Free  storage  areas  are  collapsed  into 

continguous  blocks  of  memory  whenever  a 


partition  is  freed. 

'50  (  2) Messages  are  of  an  arbitrary  yet  specified 
length., 

51  (5):  Any  number  of  messages  may  be  queued. 

60  (  9) :  User  processes  cannot  dynamically  allocate 

memory. 

MS  3-B  Protection:; 

34  (  9)::  Memory  must  be  protected  to  prevent  the 

simultaneous  allocation  of.  a  partition  to 
multiple-  job3i 

59  (  7) :  Dynamically  created  processes  must  run  in  the 
same  partition  as  the  parent  job. 

62  (  4):  The  user  processes  run  in  the  problem  states 

Main  Subprobiem  4:  Supervisor  Process: 

18  (  6)  :=  Supervisor  process  must  create  and  delete 
the  environment  in  which  a  job  runs. 

27  (10):  Supervisor  routine  must  reclaim  all  system 

resources  when  a  job  has  completed. 

28  (  9) :  Supervisor  process  must  reclaim  all  system 

resources  when  an  error  condition  abnormally 
terminates  a  job. 

61  (  6) :  User  cannot  destroy  system  process  within 

the  same  process  group. 

Main  Subprobiem  5:  Device  Management  Functions: 

36  (16) ;  Operating  system  must  supply  a  device  manage- 
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ment  routine . 

38  (IQ). ;  Ail  devices  are  allocated.. 

*  39  (  9)  :  Device  handler  routine  supports  one  card 
reader/input  stream. 

40  (6):  Device  handler  must  support  one  line  printer/ 

output  stream. 

41  (  Bht  I/O  devices  operate  via  multiplexor  channel. 
42.  (  7):  The  user  can  provide  his  own  routines  for 

non-standard  devices . 

64  (  6)t  The  user's  job  can  reference  1  input,  1  output 
1  exceptional  type  of  device. 

Main  Subproblem  6:  Message  Facility: 

46  (12) ;  A  message  facility  must  be  provided. 

48. (  5) :  The  name  of  the  sending  process  must  be  pre- 
fixed;  to  a  message. 

49  (  7) :  The  receiving  process  must  read  the  name  and 
text  of  a  message. 

52  (  2) :  All  messages  are  released  when  a.  process 

terminates . 

53  (  4) :  The  receiver  of  a  message  may  destroy  the 

message  without  acknowledgement. 

54  (  5):.  if  no  messages  are  available  to  a  process  which 

expects  one,  it  gets  blocked. 


L' 


i.  Design;  .'Philosophy 

1.  The  operating'  system  must  be  simple  f  implementing 
a  basic  system  nucleus . 

DEFINITION:  The  operating  system  is  to  be  simple 
in  the  sense  that  it  is  to  implement  only  those 
features  most,  essential  for  learning  the  funda¬ 
mentals  of  the  operating  system.  Therefore,  the 
system  is  to  implement  a  basic  system  nucleus 
to  include  the  following  features: 

—  Multi-programming ; 

-  Basic  multi-programming  support? 

—  Dynamic  memory  allocation; 

—  Device  management? 

—  Simple  top  level  supervisor;  and 
—  Traffic  control. 

IMPLICATIONS . FOR  DESIGN:  The  nucleus  does  not 
include  the  following: 

- —  language  processors; 

-  utility  programs; 

- —  spooling; 

—  file  systems; 

—  application  packages; 

—  debugging  facilities;  and 

—  subroutine  libraries. 

2.  The  operating  system  must  be  designed  as  a  peda- 
gocial  tool. 


DEFINITION;  Since  the  operating  system,  is  to  be 
used  as  an  instructional  tool,  simplicity  and 
easy  identification  of  the  major  functions  are 
the  objectives  of  the  design.  As  .previously 
described-,  the  heirarchical  operating  system 
structure  enables: 

-  easy  identification  of  the  relevant  sections 

for  processor  management,  memory  management, 
and  device  management;  and 
- identification,  of'  the  well-defined  inter¬ 
faces  between  the  various  functional 
section. 

IMPLICATIONS  FOR  DESIGN:  The  design  concepts  of 
extended  machine  instructions  and  \eirarchical 
operating  system  structure  have  been  selected? 
as  the  optimum  method  of  satisfying  the  design 
objective. 

Also  the  pedagocial  c" i  tty  of  the  operating 
system  is  preferred  to  performance. 

The  operating  system  must  be  process  oriented. 
DEFINITION :  The  requirement  is  vague  as  it 
stands,  yet  it  recognizes  the  fact  that  there 
are  certain  requirements  necessary  to  support  a 
process.  The  following  entities  exist  within 
the  system: 

-  job  stream:  sequential? 


job:  collection  of  activities  needed  to  do 
the  work  required; 

- —  process  group:  processes  belonging  to  the 
same  job;  and 

-  process:  a  system-created  entity  which  is 

the  smallest  computational  entity  with  which 
the  system  must  deal. 

IMPLICATIONS  FOR  DESIGN:  Therefore,  the  opera¬ 
ting  system  must  provide  certain  basic  functions 
by  the  extended  machine  including: 
r —  P-V  operations; 

r—  basic  multi-processing  support;  and 
- —  traffic  controlling. 

The  software  functions  can  be  thought  of  as  being 
executed,  in  the  same  way  as  hardware  instructions. 
Again,  the  basic  functions  represent  what  the 
operating  system  must  accomplish;  the  extended 
machine  implements  the  requirements; 

Design  Constraints 

4.  The  operating  system  must  be  small;  occupying 

fewer  than  2500  cards  of  assembly  language  state¬ 
ments  . 

DEFINITION :  It  was  not  clear  from  the  system 
description  that  the  requirement  occurred  "post 
hoc,  ergo  propter  hoc". 

If,  in  fact,  this  was  a  design  constraint 
then  it  must  be  analyzed  in  conjunction  with  the 


requirements  for  simplicity  and  a  basic  nucleus. 
Glearly  adding,  more  simplistic  capabilities  to 
the  system  increases  the  number  of  assembly 
language  statements  and  at  some  point,  would 
conflict,  it  was  assumed  that  since  the  actual 
operating  system  deck  2500  that  this  require¬ 
ment  was  not  significant;.. 

The  operating  system  is  to  be,  implemented 
utilizing  IBM  System/360  hardware. 

DEFINITION :  This  simple  requirement  has  far- 
reaching  significance  for  the  design;  specifi¬ 
cally,  the  hardware  constraint  has  implications 
for  the  following  functions: 

—  IBM/360  is  a  two  state  machine; 

(problem,  supervispr  states  identified) 

—  Protection  is  provided  in  2K  blocks; 
(protection  must  be  provided'  to  match  memory, 
allocation  is  in  2K  blocks) 

- —  Interrupt  mechanisms  are  hardware  functions 
which  dictate  what  sort  of  interrupts  are 
recognized  and  how  they  are  processed. 
IMPLICATIONS  FOR  DESIGN:  Since  the  guidelines 
for  defining  requirements  called  for  indepen¬ 
dence  among  requirements,  it  was  not  clear  if 
the  implication  of  the  constraint  needed  to  be 
stated  explicitly  as  requirements. 
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Sincie  the  design  constraints  were  not 
assessed  with  the  remaining  design  requirements,, 
it  was  decided  to-  draft  the  implications  of  the 
design  constraint  and  to  include  these  in  the 
assessment  -process. 

6.  The  input/output  devices  are  limited  to  card 
reader  for  input  job  streams,  and  line  printers 
for  output. 

DEFINITION:  This  was  a  design  constraint, 
imposed  "a  priori" t  which  limits  both  the 
flexibility  and  complexity  of  the  operating 
system. 

IMPLICATIONS  FOR  DESIGN:  This  requirement 
reduces  the  variety  of  hardware  and,  therefore, 
the  scope  of  the  device  management  functions  of 
the  operating  system.  The  impact  of  the 
requirement  is  specifically  written  into 
subsequent  requirements . 

Ill .  Design  Requirements 

7.  The  operating  system  must  provide  for  a  multi¬ 
programming  environment. 

DEFINITION:  Multi-programming  -  multiple  job 
streams  from  different  sources. 

IMPLICATIONS  FOR  DESIGN:  The  operating  system 
must  have  the  facilities  for: 

—  input  stream  interpretation  -  those 
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functions  which  delineate  jobs  and  job*  steps;, 
job-  control  -  those,  functions  of  the  operating, 
system  which  control  the  processing  of  a  job 
in  the  system;  and 

—  job  scheduling  -  those  functions  which  pre¬ 
pare  a  job  for  execution. 

Limitations  on  Multi-programming:  There  must 
be  some  sort  of  a  limit  established  for  the 
number  of  jobs  that  the  operating  system-  can 
handle.  In  fact/  the  system  is  limited  by: 

1.  15  protection  keys; 

2.  the  number  of  I/O  stream  must  equal  the 
number  of  devices;  and 

3.  the  amount  of  memory  available. 

The  operating  system  must  run  on  a  machine  that 
has  two  distinct  states. 

DEFINITION:  The  two  states  are  problem  state 
and  supervisor  state.  This  requirement  implies 
first  that  user  programs  execute  in  the  problem 
state,  and  second,  a  processor  can  correctly 
execute  privileged  instructions  only  in  the 
supervisor  state.  Privileged  instructions 
include  requests  to: 

- —  change  the  state  of  the  machine; 

-  start  I/O; 

—  change  the  protection  rights  of  memory;  and 
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change  the  interrupt  states  of  -the  machine:. 
Since  the  operating,  system  includes  the  imple¬ 
mentation  of  the  extended  machine  concept , 
these  instructions  may  take  advantage  of  the 
dual  state  machine  by  making  system  routines 
unavailable  to  the  user  and,  therefore,  only.' 
certain  selected  routines  are  user  callable. 
IMPLICATIONS  FOR  DESIGN:  Therefore,  the 
operating:  system -must  have  the  capability  to: 

—  distinguish  machine  state? 

— identify  privileged  instructions?  and 

—  identify  user-callable  extended  machine 
instructions . 

9.  All  resource  requests  must  pass  through  the 
supervisor  process. 

DEFINITION:  The  supervisor'  routine,  is  a  top- 
level  process  that  establishes  the  environment 
in  which  a  job  will  execute.  Initially,  all 
resources  required  by  a  given  job  are  stated, 
explicitly  on  JCL  cards.  The  supervisor  routine 
coordinates  requests  for  resources  prior  to 
creating  a  process  for  the  job. 

IMPLICATIONS  FOR  DESIGN :  The  tasks  which  the 
supervisor  must  perform  are  as  follows: 

-  allocate  memory? 

—  allocate  devices  required? 


10. 
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•r—  read  the  user  deck  into  his  partition;. 

- —  start  user  process;,  and 
—  upon  completion,  reclaim  all  resources. 

System  resources  must  be  allocated  to  a  job 
prior  to  the  job  being,  made  .eligible  to  run. 
DEFINITION:  The  specific  resources  consist  of 
memory  and  input/output  devices. 

IMPLICATION  FOR  DESIGN:  These  resource  allo¬ 
cations  are  made  at  a  job  level.  There  are  other 
resources  which  are  allocated  at  the  process 
level. 

11.  A  process  must  -be  ready  to  run  prior  to  being 
allocated  a  processor. 

DEFINITION:  Resources  required  at  the  process 
level  consist  of  only  the  processor. 

IMPLICATION  FOR  DESIGN:  Since  resource  alloca¬ 
tions  are  made  at  the  process  level,  there  must 
be  a  traffic  controller  routine  to  create  a 
process-oriented  environment  and  the  system  must 
have  some  means  of  determining  when  a  process  is 
not  eligible  to  run. 

12.  User  communication  with  the  operation  system  is 
via  special  call. 

DEFINITION:  What  need  has  the  user  of  communi¬ 
cating  with  the  operating  system?  Once  all  the 


resources  are  allocated:,  must  there  by  any 
communication?  These  questions  require  the  user 
to  communicate  with  the  operating  system: 

— —  create  a  process; 

—  destroy  a  process; 

halt  job  and.  signal  supervisor; 

— -  find:  a  PCB  given  its  name; 

-—  read  a  message; 

—  send  a  message; 

—  start/stop  process;  and 

—  abnormally  terminate  the  job. 

IMPLICATIONS  FOR  DESIGN:  The  operating  system 
must  take  action  based  on  the  user  requests. 

The  operating  system  must  protect  user  jobs  from 
each  other. 

DEFINITION:  Protect  in  this  sense  means  to 
prohibit  unauthorized  access  to  memory  locations. 
IMPLICATIONS  FOR  DESIGN:  For  purposes  of  this 
system,  a  separate  supervisor  process  exists  in 
a  separate  process  group  for  each  job  stream. 
There  is  no  communication  between  process  of 
different  jobs;  therefore,  they  essentially  are 
invisible  to  each  other. 

The  operating  system  must  utilize  information 
tables  to  .monitor  and  control  processing. 
DEFINITION:  The  operating  system  must  maintain 


information  on  a  varying  number  of  jobs, 
processes,  and-  resources;  This  requirement 
attempts  to  identify  the  table  and  thereby  mini¬ 
mize  proliferation  and  redundancy  of  system 
information. 

IMPLICATIONS  FOR  DESIGN:  The  following  informa¬ 
tion  tables  exist  in  the  sample  operating  system: 

—  nucleus  databases; 

-  process  control  block  -  one  per  process 

containing  save  areas,  used  by  the  system 
routines  for  storing  the  status  conditions, 
and  semaphores; 

—  memory  -  free  storage  blocks; 

—  processor  management  -  message  facility;  and 

—  device  management  -  unit  control  block 
stored  in  a  permanently  allocated  area  for 
every  unit. 

Notice*'  that  as  previously  stated,  the  emphasis 
for  all  transactions  is  at  the  process  level; 
therefore,  the  process  control  block  contains 
most  of  the  system  information. 

System  tables  can  be  dynamically  allocated  and 
released. 

DEFINITION:  System  tables  refer  to  those  tables 
built  and  maintained  by  certain  system  processes. 
These  tables  include: 


—  process  control  block; 

- semaphores:; 

—  free  storage  block;  ■ 

— message;-  and 

— —  unit  control  block. 

IMPLICATIONS  FOR  DESIGN:  The  operating  system 
must  'be  capable’  of  dynamically  allocating  memory 
to  itself  for  these  tables. 

A  possible  deadlock  could  occur  at  the  point, 
of  a  user's  program  which  consumed  all  of  memory; 
namely  by  continually  writing  messages.  The 
system  has  no  built-in  limiting  functions  to 
identify  such  overrun  conditions. 

Certain  system  routines  are  user  callable. 
DEFINITION ;  The  nucleus  routines  are  the  SVC 
instructions  of  the  extended  machine  concept. 

Some  of  the  routines  allow  unrestricted  memory 
reference  and,  therefore,  are  not  available  to 
the  user. 

IMPLICATIONS  FOR  DESIGN:  When  an.  SVC  instruction 
is  issued,  the  handler  routine  must  check  to 
see  if  the  operation  requested  is,  in  fact,  user- 
callable. 

System  process  routines  are  re-entrant  and 
shared. 
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DEFINITION :  System  process  have  only  one  copy 
resident  in  the  system.  Therefore,  they  must  be 
efficiently  shared  in  a  multi-programming 
environment.  Pure  procedure  operates  only  on 
variables  in  registers  or  in  separate  data  seg¬ 
ments  associated  with  the  job. 

IMPLICATIONS  FOR  DESIGN:  The  need  for  pure 
procedure  is  driven  by  the  need  for  a  multi¬ 
programming  environment.  The  system  can  set 
lpcks  through  the  P-V  operations  to  prevent 
race  conditions* 

18*  Extended  machine  instructions  are  executed  in  the 
supervisor  ptate. 

DEFINITION:  The  extended  machine  instructions 
along  with  the  normal  hardware  instructions, 
comprise  the  nucleus  of  the  system.  SVC  handler 
is  used  to  activate  the  extended  machine 
instruction  and  transfer  between  loads. 
IMPLICATIONS  FOR  DESIGN:  When  an  SVC  instruc¬ 
tion  is  issued,  a  supervisor  call  interrupt 
occurs  and  control  is  transferred  to  SVC 
handler  routine.  Therefore,  an  SVC  handler 
interrupt  must  be  provided. 

19.  The  supervisor  process  must  schedule  jobs  and 
prepare  the  jobs'  for  execution. 

DEFINITION:  The  supervisor  routine  initially 


creates  a  .process-.  The  user  may  generate  his. 
own  processes  by  SVC  instructions  during 
execution  of.  his  process  group.  This  require¬ 
ment  deals  only  with  establishing  the-  USER  PROG 
and  not  with  specific  resource  allocations. 
IMPLICATIONS  FOR  DESIGN:  This  requirement  is  an 
•explicit  statement  of  one  of  the  functions  of 
the  supervisor  process.  The  following  instruc¬ 
tions  apply: 

---  a  non-system  process  cannot  stop  a  system 
process;  and 

— -  a  process  must  be  stopped  prior  to  its  being 
deleted. 

Initially  one  process  is  created  for  each  user’s 
job. 

DEFINITION:  One  process  is  created  by  the 
supervisor  process  after  all  job  level  resources 
have  been  allocated  to  the  job. 

IMPLICATIONS  FOR  DESIGN:  The  user  must  create 
any  additional  processes  desired  on  his  own. 

Jobs  are  initiated  strictly  on  a  first-come, 
first-served  basis. 

DEFINITION:  Jobs  are  read  into  the  system  in 
the  form  of  job  streams  from  card  readers. 

Jobs  are  accepted  into  the  system  as  long  as 
sufficient  resources  exist.  Since  there  is  no 


spooling  capability,  a  job  cannot  be  copied  in 
the  system.  Once  in  the  system,  user  jobs  are 
redefined  in  process  groups  which  contend  for 
the  processor  in  a  multi-programming  environment. 
IMPLICATIONS  FOR  DESIGN:  The  supervisor  process 
must  determine  if  it  can  schedule  a  job  before 
reading  it  into  the  system. 

The  supervisor  process  must  be  modularized  so 
that  improvements  to  the  system  can  be  easily 
accomplished. 

DEFINITION;  The  system  description  indicated 
that  sophistication  of  job  scheduling  is  limited 
by  the  brevity  of  the  implementation.  There¬ 
fore,  the  system  could  easily  be  extended  to 
provide  more  advanced  features  and  facilities . 
Modularization  of  the  function  was  critical,  not 
for  pedagogical  clarity,  but  to  provide  for 
system  improvements . 

IMPLICATIONS  FOR  DESIGN?  Although  modularized 
design  was  emphasized  as  a  design  philosophy  for 
pedagogical  clarity,  it  is  now  emphasized  to 
allow  easy  improvement.  This  function  should  be 
designed  incorporating  interface  features  easily 
adaptable  to  a  system  which  will  implement 
advanced  features  such  as  spooling. 
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23.  The  process  scheduler  must  time-slice  CPU 
usage  among  ready  processes  to  achieve  multi¬ 
programming  . 

DEFINITION:  Traffice  controller  resides  in  the 
process  management/  lower  level/  and  enables  a 
process  to  run  until,  a  certain  time  quantum  has 
elapsed?  at  which  time,  the  process  is  stopped 
and  another  started.  A  process  is  ready  when  it 
is  not  blocked  or  waiting  for  the  completion  of 
some  external  event  such  as  I/O  operation  or  for 
a  message  from  another  process. 

IMPLICATIONS  FOR  DESIGN-:  The  traffic  controller 
schedules  ready  process  in  a  round-robin  fashion. 
Interrupts  must  be  enabled  to  identify  when  a 
process : 

---  exceeds  its-  time  quantum; 

— -  becomes  blocked?  and 
—  relinquishes  control  to  the  traffic 

controller  to  await  the  completion  of  an 
external  event. 

24.  Ready  processes  are  scheduled  in  simple  round- 
robin  fashion  by  the  process  scheduler. 
DEFINITION:  Round-robin  scheduling  means  that 
processors  are  sequentially  scanned  until  a 
ready  process  is  found. 


( 
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IMPLICATIONS  FOR  DESIGN:  The  traffic  controller 
must  maintain  a  current  list  of  processes  from 
which  to  select  the  next  ready  process. 

25.  A  process  must  be  blocked  and  control  released 
to  the  process  scheduler  when  a  time  quantum  of 
50  ms  is  exceeded. 

DEFINITION:  Timer  runout  trap  must  be  indicated 
when  a  process  exceeds  its*  time  quantum-.  By- 
blocking  a  process  is  meant  that  it  is  ineli¬ 
gible  to  run  temporarily. 

IMPLICATIONS  FOR  DESIGN:  Interrupt  mechanism 
must  be  provided  to  detect  a  time  runout. 

26.  A  process  shall  be  blocked  and  control  passed 
to  the  process  scheduler  when  the  process  must 
wait  for  synchronization  with  another  process. 
DEFINITION:  Multiple  process  creation  may 
require  that  one  process  await  the  completion  of 
a  previous  process  in  order  to  run. 

IMPLICATIONS  FOR  DESIGN:  Some  mechanism  (basic 
primitives)  must  be  provided  for  the  synchroniza¬ 
tion  of  processes. 

27.  A  process  shall  be  blocked  and  control  passed 
to  the  traffic  controller  when  the  process 
specifically  relinquishes  control  to  the  process 
scheduler. 

DEFINITION :  A  user  process  may  actually  finish 


execution  and  relinquish  control  to  the  traffic 
controller. 

IMPLICATIONS  FOR. DESIGN?  User  process:  >must 
signal  termination  stop  process  instructions,  or 
abnormal  termination. 

The  supervisor  process  must  reclaim  all  system 

resources  from  a  job  when  the  job  has  completed. 

DEFINITION;  Reciaimation  of  resources  is 

accomplished  on  a  job  level,  since  processes 

only  gain  the  use  of  a  processor. 

IMPLICATIONS  FOR  DESIGN;  This  requirement 

implies  successful  completion  of  a  job;  there 

are  such  things  as  unsuccessful  completions. 

The  supervisor  must  at  this  point; 

-  print  a  message  on  the  printer; 

— —  destroy  all  processes  created  for  or  by  the 

* 

user  job; 

free  memory  partition’,,  and 
-  move  on. 

A  message  must  be  available  to  signal  successful 
completion . 

The  supervisor  process  must  reclaim  all  system 
resources  when  an  error  condition  is  caused  which 
terminates  processing  for  a  process. 

DEFINITION;  An  error  in  one  user  process  which 
reaches  the  supervisor  level,  is  capable  of 
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terminating  processing  for  the  entire  process 
group . 

IMPLICATIONS  FOR  DESIGN: 

—  certain  error  conditions  must  be  defined, 
remember  that  this*  system  does  not  have 
debugging  facilities ; 

—  the  supervisor  must  perform  the  same  func¬ 
tions  as  in  the  previous  requirement?  and 

—  an  error  message  must  be  .provided. 

30.  Reference  to  processes  within  a  process  group 
is  by  symbolic  name. 

DEFINITION;  In  order  to  communicate  back  and 
forth  user  processes  must  be  able  to  identify 
each  other.  Therefore,  each  process  is  given  a 
name  by  the  process  that  creates  it. 
IMPLICATIONS  FOR  DESIGN: 

—  each  process  must  be  named  by  the  process 
creating  it;  and 

— *  each  process  must  have  a  unique  name  field 
in  order  to  identify  it. 

31.  The  operating  system  must  allocate  memory  for  a 
job,  the  size  of  which  is  to  be  specified  by 
the  user. 

DEFINITION:  The  operating  system  provides 
routines  that  will  allocate  a  block  of  memory 
of  a  given  size  and  given  address  alignment 
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using  a  best-fit  algorithm. 

IMPLICATIONS  FOR  DESIGN: 

— -  user  must  specify  the  job  partition  size 
required  by  JCL? 

-  the  operating  system  must  maintain  a  list 

of  storage  areas,  accomplished  using  free 
storage  block  list?  and 

—  a  queue  is  established  for  those  jobs 
awaiting  memory. 

32.  Memory  is  allocated  to  a  job  in  contiguous  2K 
blocks . 

DEFINITION:  Partitioned  allocation  for  user's 
jobs  is  a  simple  memory  requirement  scheme 
which  facilitates  multi-programming.  A  block  is 
a  uniquely  named  group  of  words  whose  addresses 
are  contiguous. 

IMPLICATIONS  FOR  DESIGN: 

—  the  user  must  specify  memory  requirements  in 
increments  of  2K?  and 

---  the  operating  system  should  allocate  memory 
such  that  the  amount  of  wasted  memory  is 
minimized. 

33.  The  operating  system  may  dynamically  allocate  , 
memory  to  itself  for  temporary  work  space  or 
traffic  areas  for  system  processes. 


DEFINITION:  All  system  tables  and  system 
processes  which  do  not:  run  in  the  user's  process 
need  temporary1  memory  allocated  to  them. 

Dynamic:  memory  allocation  means  that  partitions 
are  created  as  required  during  processing.  The 
operating  system  may  use  these  areas  for: 
work  space  for  system  processes?  or 

—  temporary  buffer  areas  for  message  storage. 
IMPLICATIONS  FOR  DESIGN:  Tables  mu3t  be  main¬ 
tained,  testing  free  and  allocated  storage  areas , 
usually  using  a  chaining  method  to  facilitate 
the  dynamic  nature  of  allocation  scheme. 

34.  Memory  is  allocated  using  a  best-fit  algorithm. 
DEFINITION:  The  memory  allocation  algorithm 
cycles  through  a  free  storage  list,  which  is 
arranged  in  ascending  order,  until  it  finds  a 
block  large  enough  to  contain  the  requested 
area.  In  order  to  minimize  breakage,  the 
allocated  area  with  the  specified  alignment  is 
selected  as  close  to  the  beginning  of  the  block 
as  possible. 

IMPLICATIONS  FOR  DESIGN: 

—  excess  memory  is  re-linked  to  a  free  storage 
list  whenever  memory  is  allocated?  and 

—  a  free  storage  list,  arranged  in  ascending 
order,  must  be  available  in  order  to 
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accomplish  the  best-fit  scheme; 

35.  Memory  must  be  protected  to  prevent  the  simul¬ 
taneous  allocation  of  a  partition  to  multiple 
jobs. 

DEFINITION;  Memory  protection  is  a  hardware 
function  in  the  IBM  System  360.  Each  partition 
is  assigned  a  protection  key  (1  through  15) . 

The  "0"  key  is  reserved  for  the  operating 
system.  Since  the  hardware  actually  associates 
the  keys  with  each  2K  byte  block  of  memory, 
partitions  must  be  multiples  of  2K,  and  all 
locks  within  a  partition  are  set  to  the  same 
value.  Access  control  functions  are  those 
functions  which  protect  an  area  of  storage 
against  unauthorized  access  by; 

—  insuring  that  all  storage  references  by  an 
executing  task  for  the  purpose  of  writing, 
executing  and/or  reading  in  that  storage 
are  are  legal?  and 

- —  provides  a  task  from  modifying  areas  of 
main  storage  beyond  the  limits. 

IMPLICATIONS  FOR  DESIGN; 

—  protection  keys  must  be  assigned  and  set  when 
memory  is  allocated?  and 


-  partition  locks  must  be  tested  prior  to 

allowing  access  to  memory. 


-  243  - 

36.  Free  storage  areas  are  collapsed  into  contiguous 
.blocks  of  memory  whenever  a  job  partition'  is 
freed. 

DEFINITION:  Since  memory  is  allocated  in  con¬ 
tiguous  blocks ,  the  operating  system  must,  re¬ 
combine  memory  partitions,  and  update  its  list 
of  free  areas . 

IMPLICATIONS  FOR  DESIGN:  Memory  is  to  be 
reconfigured  and  the  list  of  free  space  updated 
and  re-ordered  whenever  a  partition  of  memory 
is  freed . 

37.  The  operating  system  must  supply  a  device  manage¬ 
ment  system  which  runs  as  a  separate  process, 
one  per  device. 

DEFINITION:  The  device  management  system: 

— -  provides  the  routine  necessary  to  issue  the 
I/O  commands; 

- —  monitors  the  I/O  devices;  and 
—  interprets  the  status  information  when  an 
I/O  interrupt  occurs.  It  must  also  maintain 
interfaces  to  process  management  interznapt 
handlers  and  event  monitoring  functions. 
IMPLICATIONS  FOR  DESIGN: 

— -  management  system  can  use  semaphores  as  locks 
against  two  processes  simultaneously 
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attempting  to  access  the  same  device;  and 
the  fielding  and.  handling  of  input/output 
interrupts  are  performance  by  a  special 
routine  that  is  involved  whenever  an  I/O 
interrupt  occurs.  It  runs  for  a  very  short 
time,  just  long  .enough  to  store  status 
information  and  perform  a  V  operation  on 
Wait-Semaphore . 

38.  Device  handler  routines  must  support  multiple 
job  streams  from  card  readers. 

DEFINITION;  Support  means  that  the  routines 
must  distinguish  among: 

—  job  control  cards; 

-  object  deck; 

—  data  cards; 

and  to  delineate  jobs  and  job  steps. 

IMPLICATIONS  FOR-  DESIGN:  Each  card  reader 
represents  an  input  job  stream. 

39.  A  device  is  dedicated  to  a  job. 

DEFINITION:  A  dedicated  device  is  allocated  to 
a  job  for  the  job's  entire  duration;  this  is 
especially  applicable  to  card  readers  and 
printers.  Allocation  is  made  by  the  supervisor 
during  job  definition. 

IMPLICATIONS  FOR  DESIGN: 

- —  a  card  reader  represents  an  input  job  stream; 


icw 
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—  a  line  printer  must  be  allocated  to  a  job 
prior  to;  the  job  being  made  eligible  to  run. 
'40.  The  device  handler  routine  supports  one  card 
reader  per  input  stream. 

DEFINITION;  I/O  that  can  be  processed  sequen¬ 
tially  to  terminate  an  I/O  stream.  A  single  card 
reader  then  is  used  to  read  in  an  entire  job 
stream. 

IMPLICATIONS  FOR  DESIGN:  The  system  can  continue 
to  accept  jobs  as  long  as  sufficient  responses 
are  allocatable.  As  soon  as  we  reach  the 
resource  limit  we  must  stop  reading  in  jobs. 

Therefore,  the  supervisor  process  must  allo¬ 
cate  resources  as  jobs  are  being  used  in  in 
order  limit  the  number  of  jobs  at  the  appropriate 
time. 

The  user  must  specify  a  name  for  his  input 
stream  on  JCL. 

41.  The  device  handler  routine  must 'support  one  line 
printer  per  output  stream. 

DEFINITION:  The  user  may  specify  a  certain 
output  device  in  his  JCL. 

IMPLICATIONS  FOR  DESIGN:  The  device  name  for 
output  must  be  specified  in  JCL. 

42.  The  user  must  provide  his  own  routines  for  non¬ 
standard  devices. 


DEFINITION-;  The  user  may  supply  his  own  routine 
to  issue  his  own  I/O  commands . 

IMPLICATIONS  FOR  DESIGN,:  The  user  must  indicate 
the  use  of  a  non-standard  device  in  his  JCL 
statements.  The  device  handler  process  must 
supply  a  routine  to  hauidle  the  interface  for 
devices  wherein  the  user  wishes  to  provide  his 
own  I/O  command's . 

A  process  synchronization  mechanism  must  be 
provided  to  serve  as  a  lock  on  a  database. 
DEFINITION;  The  process'  synchronization 
mechanism  is  the  P-V  operations  used  in  conjunc¬ 
tion  with  semaphore. 

—  P  operation  -  of  value  >0  then  value  *  Value-1 

if  value  £  0  then  value=*value-l 
and  the  process  is  ineligible 
or  blocked. 

- —  V  operation  -  if  No  processes  are  ineligible 

then  value=value+l 

if  there  is  a  process  ineligible 

then  value*value+l 

and  the  waiting  process  is 

eligible. 

—  Applications  -  the  semaphore  when  the  initial 

value=l  can  serve  as  a  lock  by 
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requiring  a  P-operation  before 
accessing  and  a  V-operation 
afterwards ,  can  insure  integrity 
of  a  resource. 

IMPLICATIONS  FOR  DESIGN:  P-V  operations  can  be- 
used  to.  provide  protection  for  databases;. 

44,.  A  process  synchronization  mechanism  must  be 

provided  for  the  timing  of  synchronous  processes. 
DEFINITION :  For  processes  which  require  synchro¬ 
nous  processing,  the  P-V  operations  can  be  used 
to  insure  that  such  synchronization  takes  place. 
IMPLICATIONS  FOR  DESIGN:  Since  P-V  operations 
are  available  only  to  system  process,  this 
technique  may  be  used  to  insure  that  system 
processes  run  in  sequential  order. 

45.  A  process  synchronization  mechanism  must  be 
provided  for  synchronization  between  the  sender 
and  receiver  in  message  processing. 

DEFINITION:  A  message  facility  is  available  to 
all  processes  for  interprocess  communication. 

The  P-V  operations  can  be  employed  by  the 
message  facility  to  insure  that  messages  are 
synchronized  and  queued. 

IMPLICATIONS  FOR  DESIGN:.  The  P-V  operation  can 
be  used  to  establish  a  message  queue  facility. 

46.  A  process  synchronization  mechanism  must  be 
provided  to  lock  a  device. 
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DEFINITION;  All  devices  are  dedicated,  one  per 
jobi  The  PrV  operation  can  be  used  to  lock  each 
device . 

IMPLICATIONS  .FOR  DESIGN:  The  P-V  operation  can 
be  used  to  lock  devices. 

47.  An  interrupt  handler  routine  must  be  provided 
for  I/O  interrupts. 

DEFINITION;  Ah  interrupt  is  an  occurrence  that 
causes  the  processor  to  take  some  immediate  action. 
The  IBM  System/360  has  a  mechanism  for  being 
interrupted,  saving  its  status,  determining  what 
general  class  of  interrupt  has  occurred,  and 
executing  an  appropriate  interrupt  handler  routine. 
IMPLICATIONS  FOR  DESIGN;  The  interrupt  handler 
determines  the  cause  of  the  following  faults  and 
calls  the  appropriate  operating  system  function. 

In  this  case,  it  calls  the  I/O  interrupt  handler. 

48.  An  interrupt  handler  routine  must  be  provided  for 
program  interrupts. 

DEFINITION ;  Program  interrupts  consist  of  inter¬ 
rupts  employed  within  the  program  structure  to 
enable  a  synchronous  processing. 

IMPLICATIONS  FOR  DESIGN:  This  facility  is 
available  only  to  system  processing  and  must  be 
provided  for  that  purpose. 

49.  An  interrupt  handler  must  be  provided  for 
supervisor  call  interrupts. 


DEFINITION;  Supervisor  call  interrupts  are 
required  to  recognize  SVC;  instructions.  This 
mechanism  is  used  to  activate  the  extended  machine 
instructions  and  to  transfer  between  levels  of 
the  system. 

IMPLICATIONS  FOR  DESIGN:  The  operating  system 
must  include  a  supervisor  call  handler. 

An  interrupt  handler  must  be  provided  to  deal  with 
external  interrupts. 

DEFINITION:  External  interrupts  are  generated 
outside  of  the  operating  system  due -to  external 
conditions;  specifically/  timer  runout  trap. 
IMPLICATIONS  FOR  DESIGN:  The  operating  system 
may  utilize  the  timer  function  to  provide  for  a 
multi-programming  environment. 

P-V  Operations  are  available  only  to  system 
processes. 

DEFINITION:  Since  the  P-V  operations  in  effect 
control  the  synchronization  of  the  operating  sys¬ 
tem  and  lock  various  resources,  they  are  available 
only  to  operating  system  processes  for  use. 
IMPLICATIONS  FOR  DESIGN:  User  processes  must  have 


another  mechanism  available  to  synchronize  their 
processing. 

A  message  facility  must  be  provided  to  all 


processes , 


-  250  - 


DEFINITION :  The  message  facility  must  be  avail¬ 
able  for  interprocess  communication  to  all 
processes  in  the  system. 

IMPLICATIONS  FOR  DESIGN:.  User  processes  must  be 
identifiable  by  name.  The  message  facility  must 
recognize : 

— -  a  sender; 

—  a  receiver; 

-—  the  size  of  the  message;  and 

—  the  text. 

The  message  facility  must  be  able  to  queue  up 
messages  to  a  given  process,  uses  memory  manage¬ 
ment  for  message  buffers,  uses  P-V  operations  to 
synchronize  message  flow. 

53.  The  process  receiving  a  message  must  be  able  to 
determine  the  originator  of  the  message. 

DEFINITION:  The  receiver  of  a  message  must  be  able 
to  determine  from  whence  it  came. 

IMPLICATIONS  FOR  DESIGN:  A  process  may  be  kept 
waiting  for  a  message  from  another  process,  as  a 
means  of  synchronization. 

54.  The  receiving  process  may  read  the  name  and  text 
from  the  originator. 

DEFINITION:  In  order  to  respond  to  a  message  the 
receiver  must  be  able  to  verify  that  it  is  the 
correct  message  from  the  correct  process.  In  order 
to  take  action  on  a  message  the  receiver  must  be 
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able  to  read  the  message. 

IMPLICATIONS  FOR  DESIGN:  The  receiver  must  have 
the  capability  to  read  the  name  of  the  originator 
and  the  text  of:  the  message,  but  this  does  not 
imply  that  the  message  must,  in  fact,  be  read. 

55.  Messages  are  of  an  arbitrary,  but  specified  length. 
DEFINITION:  The  message  facility  must  allow  for 
a  valuable  message  size. 

IMPLICATIONS  FOR  DESIGN:  The  message  queue  must 

be  dynamically  allocated  space  since  the  number 

£ 

and  size  of  messages  is  variable.  Note  that  no 
limit  is  specified  for  the  number  of  messages. 

.56.  Any  number  of  messages  for  a  given  process  may  be 
queued  while  waiting  to  be  read  by  the  process. 
DEFINITION:  A  process  can  have  a  varying  length 
queue  of  messages  waiting  to  be  read. 

IMPLICATIONS  FOR  DESIGN:  Each  process  has  a 
variable  length  message  queue  which  is  dynamically 
allocated. 

57.  All  messages,  enqueued  for  a  given  process  to  read, 
are  released  when  that  process  terminates. 
DEFINITION:  When  a  process  terminates,  all 
messages  waiting  to  be  read  are  freed. 

IMPLICATIONS  FOR  DESIGN:  This  is  performed  within 
the  destroy  process  SVC  by  freeing  memory  used  to 
store  the  messages. 


o 
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58,.  Messages  are  not  receiptable  for,  from  receiver  to 
sender. 

DEFINITION:  The  receiver  of  a  message  does  not 
have  to  acknowledge  receipt  of  any  message  to  the 
sender . 

IMPLICATIONS  FOR  DESIGN:  If  the  message  facility 
cannot  locate  the  process  for  which  the  message 
was  intended  an  error  condition  is  caused. 

59.  If  no  messages  are  available  to  a  process  which 
expects'  one,  it  may  go  blocked. 

•DEFINITION :  The  message  facility  can  be  used  for 
process  synchronization;  therefore,  a  process  is 
blocked  until  properly  synchronized. 

IMPLICATIONS  FOR  DESIGN:  The  user  has  a  mechanism 
for  the  synchronization  of  various  processes. 

60.  User  programs  utilize  a  job  control  language 
statement  to  specify  resource  requirements. 
DEFINITION:  Job  Control  Language  is  the  means  by 
which  a  user  specifies  and  quantifies  his  resource 
requirements  to  the  operating  system.  For  the 
purposes  of  the  sample  operating  system,  the 
simplified  JCL  must  specify: 

-  memory  size  required; 

-  name  of  input  device  type; 

- —  name  of  the  output  device  type?  and 
—  non-standard  device  for  which  the  user  will 
supply  his  own  handler  routine. 
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IMPLICATIONS  FOR 'DESIGN; 

- —  JCL  card  is  used  to  delineate  job  -boundaries; 
—  It  must  be  .the  first  card  of  the  deck  so  that 
resource  requirements  may  be  determined. 

61.  The  operating  system  must  accept  input  data  from 
the  user's  job  stream. 

DEFINITION ;  The  user  may  input  data  to,  be  read 
and  used  in  execution  of  the  object  deck. 
IMPLICATIONS  FOR  DESIGN:  The  supervisor  must  be 
capable  of  distinguishing  among.  JCL,  object  deck, 
and  data  cards  for  any  job. 

62.  The  supervisor  process  must  load  the  user-supplied 
object  deck  into  the  user  area  of  memory. 
DEFINITION:  Once  the  supervisor  has  allocated  the 
resources  required  for  the  user's  job,  the  user's 
object  deck  is  read  into  his  partition. 
IMPLICATIONS  FOR  DESIGN:  This  is  a  function  of 
the  supervisor  process. 

63.  All  processes  may  dynamically  create  additional 
processes. 

DEFINITION:  The  user  has  the  SVC  instructions 
available  to  him  which  allows  the  creation  of 
additional  processes. 

IMPLICATIONS',  FOR  DESIGN:  The  user  processes  run 
in  the  same  partition  and  state  as  the  initially 
created  user  process.  The  user  may  destroy  only 
user  created  processes. 
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<54.  Dynamically  created  processes'  run  in  the  same 
memory  area  as  the  parent  job. 

DEFINITION:  Dynamically  created  processes  must 
share  the  memory  partition  allocated  to  the 
parent  job  and  have  the  same  protection  attributes 
assigned. 

IMPLICATIONS  FOR  DESIGN:  Dynamically  created  user 
processes  must  be  identifiable  and  are  protected 
from  other  jobs  in  the  same  manner  as  is  the 
parent  job. 

65.  User  processes  cannot  dynamically  allocate  memory. 
DEFINITION:  This  is  directly  implied  by  #59. 

Since  user  created  processes  run  in  the  partition 
of  the  parent  job,  no  more  memory  is  needed. 
However,  some  people  will  attempt  to  get  more 
memory  than  they  can  use. 

IMPLICATIONS  FOR  DESIGN:  The  user  must  specify  the 
memory  requirements  of  the  entire  job,  including 
dynamically  created  processes,  once  and  be  satis¬ 
fied  with  it.  Attempting  to  exceed  the  user's 
memory  partition  will  generate  an  error. 

66.  User  processes  can  destroy  other  user  processes 
only  within  the  same  process  group. 

DEFINITION :  System  processes  are  created  for  the 
use  of  the  operating  system  and  must  be  maintained. 
These  processes  consist  of  supervisor  process  and 
device  handler  process. 
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TRIPLICATIONS  FOR  DESIGN:  System  processes  must  be 
Identifiable  and  protected  from  user  destruction. 

The  user  destroys  a  process  by  unlinking  the  PCB, 
system  processes  do  not  have  a  specified  PCB. 

67.  User  processes,  run  in  the  problem  state. 

DEFINITION;  The  problem  state  is  one  of  two 
states  defined  by  the  IBM  System/360. 

IMPLICATIONS  FOR  DESIGN;  System  processes  are 
protected  from  user  violation  and/or  destruction 
by  the  two  state  .machine  concept. 

68.  The  user  process  must  signal  completion  (successful 
or  unsuccessful)  to  the  operating  system. 

DEFINITION;  A  completion,  signal?  i.e.,  stop 
process#  is  required  so  that; 

— —  traffic  controller  may  schedule  a  process;  and 

—  supervisor  process  may  reclaim  system  resources 
at  the  end  of  a  job. 

IMPLICATIONS  FOR  DESIGN: 

-  user  processes  may  only  stop  user  processes; 

—  a  process  must  be  stopped  before  it  is  destroyed. 

69.  The  user’s  job  can  reference  at  most:  1  input 
device,  1  output  device,  1  non-standard  devices. 
DEFINITION:  The  operating  system  will  allow 
references  to  only  one  each  of  the  three  degrees 
types. 

IMPLICATIONS  FOR  DESIGN;  l/O  commands  operate  as 
streams  unless  otherwise  specified  by  the  user  in 
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the  handling  of  exceptional  devices. 

70.  There  is  one  supervisor  process,  per  job  stream. 
DEFINITION:-  The  supervisor  process  must  schedule 
all  jobs  and  prepare  them  for  execution  by  calling 
other  appropriate  modules  of  the  system.  Functions 
of  the  supervisor  process  include: 

- —  determines,  the  amount  of  memory  required; 

---  set  storage  protection  keys? 

- —  starts  a  process  in  an  interface  :routine  for 

each  device? 

reads  in  the  user '  s  object  deck? 

-  user  process  starts  to  run?  and 

—  upon  completion,  the  supervisor  process 

destroys  all  processes  created  for  or  by  the 
user  frees  memory  and  devices. 

IMPLICATIONS  FOR  DESIGN:  The  supervisor  process 
acts  as  the  interface  between  the  user  and  the 
operating  system. 

71.  The  I/O  interrupt  handler  routine  must  provide  for 
a  synchronous  scheduling  of  a  process  requiring 
fast  processing. 

DEFINITION:  The  interrupt  mechanism  transfers 
control  to  the  traffic  controller  causing  the 
process  waiting  for  the  interrupt  to  start  running 
immediately.  It  is,  therefore,  possible  to  attain 
very  fast  processing  of  exceptional  interrupts. 
IMPLICATIONS  FOR  DESIGN:  Interrupt  routine  trans- 

■ .  rr 


A 
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fers  control  directly  to  the  traffic-  controller  in 
order  to  run  a  new  process. 

72.  System  Initialization:  The  operating,  system  must 
include  a  non-system  resident  task  which,  loads  the 
0/S:  into  the  computer  and  defines  the  processing 
environment. 

DEFINITION :  Initial  program  load  routine  runs 
free  of  most  of  the  rest  of  the  system ,  and 
serves  to  initialize  supervisor  process  and  SVC 
routines,  essentially  by  initializing  PCB 
entries  and  free,  storage  blocks  for  memory. 
IMPLICATIONS  FOR  DESIGN:  This  system  is  used 
infrequently  and  depends  heavily  upon  the  final 
implementation  design  in  order  to  carry  out  its 


functions . 
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Note  X: 


Note  2: 


APPENDIX  H 

Pinal  Interdependency  Assessment 
Results 


(s)  Indicates  that  the  requirement  indicated 

supports  the  implementation  of  the  require¬ 
ment  being  assessed. 

(c)  Indicates  that  the  requirement  indicated 
conflicts  with  the  implementation  of  the 
requirement  being  assessed. 

Requirements  1  through  6  were  not  assessed 
for  the  reasons  stated  in  4.1.10. 


The  operating  system  must  provide  for  a  multi¬ 
programming  environment. 

10 |s) :  Resource  allocation  is  performed  as  a  job  is 

read  into  the  system,  except  for  process 
allocation. 

13 (si:  A  multi-programming  environment  must  include 

job  protection  mechanism. 

14  (s) :  Information  tables  are  the  mechanism  by  which 

the  operating  system  monitors  and  controls  the 
multi-progr.amming  environment. 

17  (s):  The  need  for  pure  procedures  is  driven  by  a 
multi-programming  environment . 

19  (s):  The  supervisor  process  creates  one  process  per 
job  initially  to  support  multi-programming. 

21  (s):  Multi-programming  environment  requires  that 
multiple  jobs  be  scheduled. 

35  (s):  Some  memory  allocation  scheme  is  required  to 

support  a  multi-programming  environment. 

40  (s) :  Device  handler  routine  facilitates  the  reading 
of  multiple  job  streams  from  different  sources. 

60  (s):  JCL  assists  multi-programming  by  delineating 
jobs  and  specifying  resource  requirements. 

70  (s):  The  supervisor  process  controls  and  synchro¬ 
nize  all  the  functions  in  a  multi-programming 
environment. 


The  operating  system  must  run  on  a  machine  that  has  two 
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distinct  states’?  i.e. ,  problem  and  supervisor. 

12 (s) ;  User  communication  with  the  operating  .system 
via  a  special  call  ensures,  that  the.  user  may  be 
restricted  -from  certain  privileged  instruc¬ 
tions.. 

16  (s) :  Only  certain  special  instructions  are  user 
callable. 

18  (s):  Special  instructions  explicitly  executed  in 
the  supervisor  state. 

49  (s):  An  interrupt  handler  must  be  available  in 
order  to  change  machine  states. 

67 (s) :  User  processes  an  restricted  to  the  problem 
state . 

9.  All  resource  requests  must  pass  through  the  supervisor 

process. 

10: (s):  All  resources,  less  processor,  must  be  allo¬ 
cated  prior  to  the  job  being  made  eligible  to 
run, 

12: (s):  Resource  requests  are  processed  as  privileged 
instructions  through  the  supervisor  process. 

""i 

28: (s):  The  resources  must  also  be  reclaimed  by  the 
supervisor. 

29: (si:  Resources  are  reclaimed  when  an  error  condition 
terminates  job  processing. 

31: (s) :  Memory  allocation  is  a  resource  request. 

37: (s) :  Device  management  is  a  resource  which  must  be 
allocated. 
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60:  (s) :  JCL  specifies  the  resources  required  of  a  job 
to  -die  supe: ryrlgqr  process  i 

70s  (s) s  The  supervisor' process  controls  all  resource 
allocations . 

10.  System  resources  must  be  allocated  to  a  job sprior  to  the 

job  being  made  eligible  to  run. 

11(c):  User  resources;  i.e.,  processes  are  allocated 

at  th6  process  level. 

19  (s):  The  supervisor  process  allocates  all  resources 
to  a  job. 

31:  (s) :  Memory  is  an  alloca table  resource. 

37:  (s)  :  The  device  handler  ..routine  is  allocated  to  a 
job  at  this  time. 

60:  (s):  JCL  enables  the,  user  to  identify  his  resource 
needs. 

70:  (s):  The  supervisor  process  controls  all  resource 
allocations . 

11.  A  process  must  be  ready  to  run  prior  to  being  allocated 

a  process. 

14  (s) :  The  status  of  a  process  is  directly  maintained 
and  controlled  by  information  tables. 

25(c):  A  process  shall  not  be  ready  if  it  exceeds  the 

time  quantum. 

26  (c) :  A  process  shall  not  be  ready  if  it  is  waiting 

to  synchronize  with  another  process. 


27  (c)  : 


A  process  shall  not  be  ready  if  it  specifi¬ 
cally  relinquishes  control,  to  the  traffic 
controller. 

59(c):  A  process  shall  not  be  ready  if  it  is  waiting 

to  receive  a  message. 

User  communication  with  the  operating  sytem  is  via 

special  call. 

16(c):  Only  certain  of  the  special  calls  are  available 

to  user  processes. 

27  (s) :  A  process  may  relinquish  control  to  the 
operating  system  via  special  call. 

46  (s):  The  process  synchronization  mechanism  is  imple¬ 

mented  using  a  special  call. 

49  (s):  The  supervisor  call  interrupt  is  generated  by 
special  call. 

52  (c) :  The  message  facility  is  another  mechanism 

4 

employed  for  user  communication. 

68  (s) :  The  user  must  signal  completion  using  a  special 
call. 

The  operating  system  must  protect  user  jobs  from,  each 

other. 

14:  (s):  Information  tables  contain  the  information 
required  to  protect  user's  jobs. 

20  (s):  The  creation  of  a  single  process  initially, 

isolates  user  jobs  from  each  other. 

The  protection  of  memory  partitions  can  be 


35  (s).: 


accomplished,  with  the  same  implementation 
utilized  f  Jie  requirement. 

64  (s ) :  As  a  protection  mechanism,  dynamically  created 

processes  run-  in-  the  memory  area  of  parent 
job . 

66{s):  To  protect  jobs,  a  process  can  destroy  only 

those  non-system  processes  within  its  process 
group . 

67  (sj :  User  processes  run  in  the  problem  state  to 

prevent  access  to  system  level  functions . 

The  operating  system  must  utilize  information  tables  to 

monitor  and!  control  processing. 

15  (s):  Dynamic  allocation  of  system  tables  is  required 
in  support  of  multi-programming  environment. 

24  (s):  Round-robin  scheduling  is  accomplished  most 

effectively  by  chaining  the  tables  together. 

32  (s) :  Memory  allocation  is  accounted  for  in  2K 

increments . 

33  (s):  The  operating  system  may  dynamically  allocate 

memory  for  information  tables. 

36  (s):  Collapsing  free  storage  areas  requires  that 

the  system  tables  be  updated. 

43  (s):  P-V  mechanism  is  used  extensively  to  restrict 

access  to  system  tables  for  protection. 

52  (s):  The  message  facility  requires  use  of  informa¬ 

tion  tables  extensively. 
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15.  System  tables  can  be  dynamically  allocated  and 
released. 

3 3' (s') :  Dynamic  memory  allocation  facility  fully 

supports  this  requirement. 

56  (s):  The  queuing  of  messages  requires  a  dynamic 
memory  allocation  facility. 

66(c).:  The  user  is  strictly  prohibited  from  dynamic 

memory  allocation. 

16.  Certain  system  routines  are  user  callable. 

18  (s):  Extended  machine  instructions  are  executed 

in  the  supervisor  state  to  provide  a  system 
check  to  determine  if  use  is  authorized. 

51  (s)  :  P-V  operations  are  specifically  restricted 

from  the  user  since  these  are  used  as  system 
locks . 

52  (s)  :  The  message  facility  is  made  available  to  all 

users  for  user  communication. 

17.  System  process  routines  are  re-entrant  and  shared. 

33  (s):  The  operating  system  maintains  pure  code  by 

dynamically  allocating  memory  for  work  space 
for  system  routines. 

37  (s) :  The  device  management  process  is  a  system 

routine  which  must  be  shared  among  many  users. 
The  process  synchronization  mechanism  is  used 
as  a  lock  to  synchronize  usage  of  certain 
routines. 


44 (s)  : 
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70  (s) :  The  supervisor  process  is  a  system,  routine 

which;  must  be  shared  among  many  jobs. 

,18.  Extended  machine  instructions  are  executed  in  the 
supervisor  state. 

49  (3) :  An  interrupt  handler  must  be  provided  to 

recognize  and  handle  extended  machine  instruc¬ 
tions  . 

67(c):  User  processes  must  run  in  the  problem  state, 

and  generate  calls  to  the  'operating  system  via 
extended  machine  instructions  for  resources*. 

19.  The  supervisor  process  must  schedule  jobs  and  prepare 
the  jobs  for  execution. 

20 (s):  The  supervisor  initially  creates  one  process 

per  job, 

21  (s):  The- supervisor  schedules  jobs  strictly  on  a 

first-come,  first-served  basis. 

22  (s):  The  functions  of  the  supervisor,  and  the  inter¬ 

faces  must  be  clearly  defined  so  that  improve¬ 
ments  may  be  easily  accomplished. 

28  (s) :  Another  function  of  the  supervisor  routine  is 

to  reclaim  all  system  resources. 

29  (c) :  The  supervisor  must  reclaim  resources  when  a 

process  generates  a  system  level  error. 

62 (s) :  The  supervisor  must  also  load  the  user's  deck 

in  order  to  prepare  a  job  for  execution. 

One  supervisor  process  exists  per  job  stream. 


70 (s) : 
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Initially,,  one  process  is  created  for  each,  user's  job. 

63  C s)':  The  user  process  may  create  additional 

processes  to  form  a  process  group  after  the 
user  process  has.  been  initiated. 

Jobs  are  initiated  strictly  on  a  first-come,  first- 
served  basis. 

22 (s):  The  FCFS  scheduling  is  simplistic;  therefore, 

we  can  improve  system  performance  at  some  later 
time  by  modularizing  this  function. 

40 (s)  :  The  fact  that  all  input  devices  are  dedicated 
card  readers,  forces  the  FCFS  implementation. 
71(c):  The  provision  for  a  fast  I/O  processing  mech¬ 

anism  may  preclude  a  job  from  being  scheduled 
•  strictly  FCFS. 

22.  The  supervisor  process  must  be  modularized  so  that 
improvements  to  the  system  can  be  easily  accomplished. 

70 (s):  Modularization  of  the  supervisor  process 

requires  that  its  functions  and  interfaces  be 
clearly  defined  so  that  any  change  in  its 
implementation  be  made  explicit. 

23,  The  process  scheduler  must  time-slice  CPU  usage  among 
ready  processes  to  achieve  multi-programming. 

24  (s):  All  processes  are  scheduled  round-robin,  so 

that  the  next  sequential  ready  process  is 
selected  for  scheduling. 
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25 (s):  The-  specific  time-slice  quantum  equals  50ms. 

50;(s) :  An  external  interrupt  is  generated  when  a 

timer  runout  is  deleted,  and  a  handler  must  be 
provided . 

25.  Ready  processes  are  scheduled  in  simple  round-robin 
fashion  by  the  process  scheduler. 

26(c):  A  process  is  not  scheduled  it  is  is  waiting 

for  synchronization  with  another  process. 

44  (s) :  A  process  synchronization  mechanism  must  be 

provided  to  enqueue  ready  processes  in  a  chain. 
,59  (s):  A  process  is  not  scheduled  if  it  is  waiting 
for  message  synchronization  with  another 
process. 

63  (s) :  User  processes  may  create  additional  processes 
which  must  in  turn1  be  scheduled. 

71(c):  The  fast  I/O  processing  mechanism  allows  imme¬ 

diate  scheduling  of  a  process,  conflicting 
with  the  round-robin  scheduling. 

25.  A  process  must  be  blocked,  when  a  time  quantum  of  50ms 
is  exceeded. 

50  (s):  An  external  interrupt  is  generated  when  the 
time  quantum  is  exceeded,  and  an  interrupt 
handler  must  process  the  interrupt. 

26.  A  process  is  blocked,  when  waiting  for  synchronization 
with  another  process. 
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44 (s):  A  process  synchronization  mechanism  is' 

provided'. 

48  (s)<:  A  program  interrupt  mechanism  is  provided  to 

enable  a  process  .to  signal  that  it  is  waiting 
for  synchronization. 

51 (s) :  Process  synchronization  mechanism  is  available 
only  to  system  processes. 

59  (s) :  The  user  processes  utilize  the  message  facil¬ 

ity  to  signal  other  user  processes  for 
synchronization. 

27.  A  process  is  blocked,  when  it  specifically  relinquish 

control  to  the  process  scheduler. 

48 (s) :  A  program  interrupt  facility  is  required  so 

that  a  process  can  signal  the  process  scheduler.. 

68 (s):  The  user  must  signal  completion  of  a  process, 

and,  thereby,  relinquish  control  of  the 
processor  to  the  process  scheduler. 

28.  The  supervisor  process  must  reclaim  all  system  resources 

from  a  job  when  the  job  has  completed. 

29(c):  The  supervisor  must  also  reclaim  resources  if 

a  user  process  generates  a  system  level  error. 

36  (s):  Free  storage  areas  must  be  collapsed  and  recon¬ 

figured  when  a  job  ends. 

37 (s):  The  device  handler  routine  for  a  particular 

job  must  be  terminated. 

43  (s):  All  system  locks  must  be  released  when  a 
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particular  job  terminates. 

46(s) :  All  devices  which  are  locked  by  the  job  must 

be  released. 

48  (s) :  The  user  must  signal  the  end  of  his  job/  and 
an  interrupt  handler  must  be  provided  to.  deal 
with  the  signal. 

68 ( s ) s  The  user  is  required  to  signal  completion. 

70  (s) :  The  supervisor  process  is  restarted  when  the 
job  ends  just  long  enough  to  clean  up  all  the 
resources. 

29'.  Supervisor  must  reclaim  system  resources  when  a  user 
process  generates  a  system  level  error. 

48  (;s)  :  Upon  generation  of  a  system  level  error  inter¬ 
rupt,  a  handler  must  take  control  and  deal 
with  the  interrupt. 

68(c):  Normally  the  user  must  signal  completion,  but 

this  requirement  dictates  that  abnormal  ending 
must  be  recognized. 

30.  Reference  to  processes  within  a  process  group  is  by 
symbolic  name. 

53  (s ) :  The  message  sending  and  receiving  recognition 

mechanism  is  strictly  accomplished  by  process 
names. 

54  (s)  :  Same  as  53 . 

63  (s):  Dynamically  created  processes  within  a  process 


group  must  be  named  as  they  are  initiated. 

64  (s) :  Processes  of  the,  same  process  group  must  run 

on  the  same  memory  area  as  the  parent  job. 

66('s)  :  User  processes  may  destroy  pther  user  processes 
only  within  the  same  process  group  by  symbolic 
name. 

The  operating  system  must  allocate  memory  for  a  job, 
the  size  of  which  is  to  be  supplied  by  the  user. 

32(c):  Memory  allocation  is  limited  to  2K  increments. 

34 (s):  Memory  must  be  allocated  using  a  best-fit 

algorithm. 

36(c):  Memory  is  collapsed  into  contiguous  blocks 

whenever  it  is  freed,  which  enables  reassign- 
ment. 

43  (s):  The  process  synchronization  mechanism  may  be 

used  to  lock  a  database  after  allocation. 

60  (s)  :  The  user  specifies  his  memory  requirements  in 
JCL. 

65(c):  Once  initial  memory  has  been  allocated,  the 

user  cannot  dynamically  allocate  memory. 

Memory  is  allocated  in  2K  blocks. 

34  (s):  The  best-fit  algorithm  is  used  to  limit  the 

wasted  memory  space. 

35  (s):  Allocation  is  2K  blocks  allows  hardware  protec¬ 

tion  of  memory  be  IBM/360  hardware. 


36  (s) :  Memory  is  configured  whenever  it  is  freed. 

43 '(s'):-  The  process  synchronization  mechanism-  can  be 
used  to  lock  a  database  once  memory  has  been 
allocated. 

60  (is).:  The  user  must  supply  his  memory  requirements 
in  2K  increments. 

65  (c) :  User  process  cannot  dynamically  allocate  memory 
whereas  system  process  can. 

Operating  system  can  dynamically  allocate  memory  to 
itself  for  temporary  workspace  or  buffer  areas  for  sys¬ 
tem  processes. 

35  (s):  Once  allocated,  memory  areas  must  be  protected 

to  prevent  simultaneous  access. 

36  (s):  Memory  must  be  reconfigured  by  the  operating 

system  whenever  a  block  is  freed. 

37  (s) :  The  device  management  system  requires  memory 

for  temporary  workspaces. 

43  (s):  The  process  synchronization  mechanism  can  be 

used  to  lock  databases. 

56  (s) j  The  message  facility  requires  dynamic  memory 
allocation  to  enqueue  messages. 

65(c):  User  processes  are  strictly  prohibited  from 

dynamically  allocating  memory. 

Memory  is  allocated  using  a  best-fit  algorithm. 

36  (s):  Memory  is  configured  when  de-allocated  to 

ensure  that  the  largest  contiguous  blocks  are 
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available  to  the  system. 

60  (s)  :  The  user  must,  specify  his  memory  requirements, 

in  a  JCL  statement. 

35.  Memory  must  be  protected  to  prevent  the  simultaneous 
allocation  of  a  partition  to  multiple  jobs. 

43  {«) :  The  process  synchronization  mechsmism  is  avail¬ 
able  to  lock  a  database. 

64  (s) :  Dynamically  created  process  must  run  in  the 

3ame  memory  partition  as  the  parent  job,  which 
further  protects  memory. 

63;(s) :  The  user  is  strictly  prohibited  from  dynami¬ 

cally  allocating  memory  which  reduces  the 
protection  requirements. 

36.  Free  storage  areas  are  collapsed  into  contiguous  blocks 
of  memory  whenever  a  job  partition  is  freed. 

68  (s) :  The  user  must  signal  completion  of  his  job,  to 
the  operating  system  so  that  memory  may  be 
reclaimed. 

37..  The  operating  system  must  supply  a  device  management 

system,  which  runs  as  a  separate  process,  one  per  device. 

38  (s):  A  device  handler  routine  must  be  included  in 

the  device  management  system, 

39  (s):  Since  devices  are  dedicated,  only  one  person 

per  device  is  required. 

40  (s):  The  device  handier  routine  is  specifically 


41 (s)  : 


required  to  support  only  one  card  reader'  per 
input  stream. 

The  device  handier  routine  is  specifically 
required  to  support  only  one  printer  per  output, 
stream. 

42 (s):  The  device  management  system  must  enable  the 

user  to  supply  his  own  routine  for  non-standard 
devices . 

46  (s):  The  process  synchronization  mechanism  is  avail¬ 

able  to  lock  a  dedicated  device. 

47  (s):  An  interrupt  handler  routine  is  provided  to 

process  I/O  interrupts. 

69  (s);  The  user  must  declare  his  devices,  and  is 

limited  to  a  card  reader,  a  printer,  and  a  non¬ 
standard  device. 

Device  handler  routines  must  support  multiple  job 
streams  from  card  readers. 

39  (s) :  Dedicated  devices  enable  sequential  processing- 

and  simplify  the'  designation  of  job  stream. 

40  (s) :  A  card  reader  represents  an  input  stream; 

hence,  multiple  car:’  readers  represent  multiple 
job  streams. 

61  (s):  One  aspect  of  the  device  handler  routine  is  to 

distinguish  among  JCL,  object  deck,  and  user's 
data. 

The  user  must  specify  which  card  reader  consti- 


69 (s)  : 
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tutes  His  input  job  stream. 

39.  A  device  is  dedicated  to  a  job. 

40  (s):  Since  devices  are  dedicated,  a  card  reader 
represents  an  input  job  stream. 

41:(s) :  Since  devices  are  dedicated,  a  printer  repre¬ 

sents  an  output  job  stream. 

42  (s):  Non-standard  devices  employed  by  the  user  must 
be  dedicated  to  his  job; 

46  (s):  The  process  synchronization  mechanism  is 
available  to  lock  a  device. 

60  (s)  :  The  user  must  identify  the  devices  used  by  a 
JCL  statement. 

69  (sj :  The  user  must  explicitly  identify  which  devices 
he  is  using. 

40.  The  device  handler  routine  supports  one  card  reader  per 

input  stream.  , 

42(c):  The  user  must  specify  his  own  handler  routine 

for  any  non-standard  devices  used. 

S(s) :  The  process  synchronization  mechanism  can  be 

used  to  lock  a  device  to  an  input  stream. 

60  (s) :  The  user  must  identify  the  devices  used  by  a 

JCL  statement. 

61  (s):  The  device  handler  must  enable  the  operating 

system  to  discern  between  JCL,  object  deck, 
and  user's  data. 

The  user  is  limited  to  one  card  reader  or  non- 


69 (s) : 
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standard  device  for  input. 

41.  The  device  handler  routine  must  support  one  line  printer 
per  output  stream. 

42(c).:  .A  user  must  supply  his  own  handler  routine  for 
any  non-standard  devices. 

46  (s):  The  process  synchronization  mechanism  can  be 
used  to  lock  a  device  for  ah  output-  stream. 

60  (s):  The  user  must  specify  a  printer  for  use  in  the 
JCL.  statement. 

69  (s):  The  user  is  limited  to  one  line  printer  or  non¬ 
standard  device. 


O 


42.  The  user  must  provide  his  own  routines  for  non-standard 
devices . 

47  (s):  An  interrupt  handler  for  I/O  interrupts  must 
recognize  that  a  user  is  providing  his  own 
device  handler  routine. 

60  (s) :  The  user  must  specify  the  use  of  a  non-stand¬ 

ard  device  in  a  JCL  statement. 

61  (s):  Any  non-standard  device  handler  routine  must 

recognize  JCL,  object  deck,  and  user's  data. 

69  (s):  The  user  is  limited  to  a  single  non-standard 

device. 


43.  A  process  synchronization  mechanism  must  be  provided 


to  serve  as  a  lock  on  a  database. 

44  (s):  The  mechanism  also  may  be  used  for  the  timing 
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of  synchronous  processes. 

45  (s):  The  mechanism  may  also  be.  used  f :r  synchroni¬ 

zation  of  the  message  facility.. 

46  (s) :  The  mechanism  may  also  be  used  to  lock  a 

device. 

51  (s) :  The  mechanism  is  restricted  to  use  by  system 

processes  only. 

44.  A  process  synchronization  mechanism  must  be  provided 
for  the  timing  of  synchronous  processes. 

45  (s);  The  mechanism  is  also  used  for -synchronization 

of  the  message  facility. 

46  (s');  The  mechanism  is  also  used  to  lock  a  device. 

51  (s):  The  mechanism  is  restricted  to  use  by  system 

processes  only. 

45.  A  process  synchronization  mechanism  must  be  provided  for 
synchronization  between  the  sender  and  receiver  in 
message  processing. 

46  (s):  The  mechanism  is  also  used  to  lock  a  device. 

51  (s):  The  mechanism  is  restricted  to  use  by  system 

processes  only. 

56  (s) :  The  mechanism  is  used  to  establish  an  ordered 
queue  for  the  message  facility. 

46.  A  process  synchronization  mechanism  must  be  provided  to 
lock  a  device. 

51 (s):  The  mechanism  is  restricted  to  use  by  system 

processes  only. 
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47.  An  interrupt  handler  routine  must  be  provided  for  I/O 


interrupts .. 

48  (s)  : 

An  interrupt  handler  routine  must  also  be  prpi- 

vided  for  program  interrupts. 

49(s),: 

An  interrupt  handler  routined-must  also  be  pro¬ 
vided  for  supervisor  call  interrupts. 

50  (s) : 

An  interrupt  handler  routine  must  also  be  pro¬ 
vided  for  external  interrupts; 

61 (s)  : 

The  interrupt  handler  may  be  utilized  to  recog 

nize  input  data  from  the -user’s  job  stream. 

71(s): 

The  interrupt  handler  must  provide  a  special 

facility  to  enable  fast  processing  of  I/O 

requests  for  non-standard  devices  requiring, 

frequent  updates. 

48.  An  interrupt  handler  routine  must  be  provided  for 
program  interrupts. 

49  (s) :  An  interrupt  handler  routine  must  also  be 
provided  for  supervisor  call  interrupts. 

50 (s):  An  interrupt  handler  routine  must  also  be 

provided  for  external  interrupts. 

68  (s) :  The  user  must  signal  process  completion  via  a 
program  interrupt. 

49.  An  interrupt  handler  routine  must  be  provided  for  super 
visor  call  interrupt. 

50 (s):  An  interrupt  handler  routine  must  also  be 

provided  for  external  interrupts. 
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52.  A  message  facility  must  be  provided  to  all  processes. 

53  (s)  :  The  message  facility  must  enable  the  process 

receiving  ;a  message  to  determine  the  origina¬ 
tor  of  the  message. 

54  (s):  The  message  facility  must  enable  the  process 

to  read  the  name  and  text  from  the  originator. 

55  (s) :  The  facility  must  be  able  to  handle  messages 

of  an  arbitrary,  yet  specified  length. 

56  (s):  The  faculty  must  use  some  sort  of  chaining  to 

queue  waiting  messages. 

57  (s) :  The  facility  must  be  able  to  release  messages 

for  a  process  which  terminates. 

58  (s) :  There  is  no  need  for  a  receiver  of  a  message 

to  acknowledge  to-  the  originator. 

59  (s) :  The  message  facility  can  be  used  for  process 

synchronization  by  blocking  processes,  expect¬ 
ing  messages. 

53.  The  process  receiving  a  message  must  be  able  to  deter¬ 
mine  the  originator  of  the  message. 

54  (s) :  The  message  determines  the  originator  by 

reading  the  name  of  the  originating  process, 
separate  from  the  text. 

58  (s) :  As  long  as  the  receiver  knows  from  whence  the 

message  came,  there  is  no  need  for  receipt. 

59  (s):  A  process  may  be  blocked  until  it  receives  the 

message  it  anticipates  from  a  specific  process. 
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54.  The  receiving  process  may  read  the  name  and  text  from 
the  originator. 

56 (s):  In  a  queue  of  multiple  messages,  a  process. 

must  be  abie  to  determine  the  name  arid  text 
of  the  originator;, 

58 (s):  As  long  as  a  process  can  read  the  name  of  the 

originator,  there  is  no  need  to  receipt  a 
message. 

59 (s):  A  process  may  be  synchronized  by  blocking  it 

until  it  receives  the  proper  text  from  a.  given 
process. 

55.  Messages  are  of  an  arbitrary  yet  specified  length. 

56 (s) :  Messages  may  be  of  a  variable  length  and 

number;  therefore,  a  queuing  process  is 
required  to  store  all  messages  dynamically. 

56.  Any  number  of  messages  to  a  process  may  be  queued  while 
waiting  to  be  used. 

57 (s) :  The  queued  messages  may  not  necessarily  be 

read  by  a  process;  therefore,  they  must  be 
released  when  that  process  terminates. 

57.  All  messages,  enqueued  for  a  given  process  to  read,  are 
released  when  that  process  terminates. 

58  (s):  A  process  may  never  read  the  messages  addressed 

to  it;  therefore,  there  is  no  facility  required 
for  receipting. 
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68  (s)  :  A  user  process  must,  signal,  completion  to  the 

operating  system  so  that  the  enqueued  messages 
for  that  process  may  be  released . 

60.  User  programs  utilize  a  job  control  language  statement 
to  specify  resource  requirements. 

61  (s):  The  operating  system  must  be  capable  of 

discerning  among  JCL,  user's  object  deck,  and 
user's  data. 

69  (s):  The  user  must  specify  I/O  devices  in  the  JCL 

statement . 

61.  The  operating  system  must  accept  input  data  from  the 
user's  job  stream. 

70  (s)  :  The  supervisor-  process  controls  the  input  of 

the  user's  job  stream  and  must,  therefore, 
separate  all  the  JCL,  user's  object  deck,  and 
data. 

62.  The  supervisor  process  must  load  the  user  supplied 
object  deck  into  the  user's  area  of  memory. 

70  (s):  The  supervisor  process  explicitly  performs  this 
function  as  it  exists,  one  per  job  stream. 

63.  All  processes  may  dynamically  create  additional  process. 

64  (s) :  Such  processes  are  limited  to  the  initial  user 

memory  area. 

66  (s):  The  user  processes  can  also  destroy  processes 

but  these  are  limited  to  user  processes  only. 
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64.  Dynamically  created  processes  run  in  the  same 'memory 
area  as  the  parent  Job. 

65  (s) :  The  user  cannot  dynamically  allocate  memory; 

therefore,  all  user  processes  must  run  in  the 
area  of!  the  parent.. 

66(s),:  User  processes  of  different  jobs  are  made 

invisible  to  each  other  and,  therefore,  can 
only  destroy  processes  within  the  same  process 
group . 

67(a)  :  The  user  processes  run.  in  the  problem  state 

and;  therefore,  are  not  capable  of  allocating 
additional  memory. 

66.  User  processes  can  destroy  other  user  processes  only 
within  the  same  process  group. 

67  (s)  :  User  processes  run  in  the  problem  state  and  in 

the  same  memory  area  as  the  parent  job;  there¬ 
fore,  user  processes  of  different  process 
groups  are  invisible  to  each  other. 
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INITIAL  PARTITION  .COMPUTED  WITH  P  =  80.00  %. 

req: 

HCM1 

BEST  PARTITION  MEASURE:'  1.263 
DO'  YOU  WANT  TO  PRINT  THE  TREE? 

NO 


req: 

:'pICL 

CLUSTER  (NO)  OBJECTS 


1 

(  8) 

1 

3 

4 

9 

An 

(  5) 

o 

6 

10 

3 

(  4) 

5 

17 

19 

4 

<  7) 

7 

14 

24 

5 

(  9) 

8 

9 

25 

6 

(12) 

11 

31 

32 

63 

65 

.7 

(  7) 

18 

20 

37' 

8 

(  5) 

21 

oo 

An  Art 

23 

9 

(  8) 

46 

47 

48 

13 

15 

16 

56 

64 

1-2 

43 

44 

57 

58 

60 

61 

26 

27 

28 

29 

30 

59 

33 

34 

35 

36 

41 

54 

33 

39' 

40 

45 

42 

62 

49 

50 

51 

52 

53 
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REG* ' 

HCM2 

BEST  PARTITION  MEASURE}'  1-276 
DO  YOU  .WANT  TO  PRINT  THE  TREE? 
>NO 


REG  ♦ 

PRCL 

CLUSTER  (NO)  OBJECTS 


1 

(11) 

1 

3 

4 

11 

13 

15 

16 

22 

23 

64 

9 

*» 

(13) 

0 

6 

10 

12 

17 

19 

'21 

41 

42 

44 

62 

65 

3 

<  9) 

5 

IS 

20 

3<{ 

38 

39 

40 

45 

,53 

4 

<;  7) 

7 

14 

24 

57 

58 

60 

61 

5 

<  %) 

(3 

9' 

25 

26 

27 

28 

29 

30 

59 

6 

(  9) 

3.1; 

3'!; 

•W 

33 

34 

35 

36 

54 

55 

63 

7 

(  7) 

46 

47 

48 

49 

50 

Si 

52 

•j 

V  P 

APT  Itt, 7)i 

ME: 

A  SURE ! 

l 

1  1 

v  r  1 1 

JQ 
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j(%  j~ *;> 

<i'i 


•'LUSiT-iF  (NO)  04..SC5' 
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«v* 


/i 


/  ■ 
o 


( 

■:>  1  , 

,  M 

3 

4 

11 

13 

15 

1  A 

56 

6-i. 

( 

Ajf 

n 

6 

11) 

i_2 

1 

I,  ■. 

5 

1,7 

10 

10 

20 

21 

9  :> 

An '»»» 

23 

a;*. 

i<2 

43 

ii  •') 

53 

62 

63 

t 

7} 

7 

i 

2« 

•=T? 

59 

J 

61 

»* 

J.  0 

q 

9 

27 

A  A 

4  7 

48 

49 

so 

51 

‘52 

( 

6 ) 

9r; 

26 

",/n 

90 

JO 

CQ 

’J  i 

{ 

O  » 

*  t 

3 .1. 

32 

33 

34 

35 

•*v  # 

■30 

54 

55 

43 

< 

5) 

37 

28 

a  5 

*!•) 

43 
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?Ti5  . 


-  289  - 


47 

48 
46 
52 
51 

49 

50 
9 

27 
8 

38 
45 

39 
37 

40 

29 
59 

25 

26 

28 

30 


I 

I 


T-* 


* 


* 


* 


measures: 


-201 ♦ 500 

-196*000 

-191,500 

“164*667 

-161,667 

-155*750 

-133*042 

-124.792 

-120,375 

-99*792 

-95.292 

-92  *  292 

-74*458 

-69,458 

-65*792 

-49*570 

-46*617 

-43*117 

-25,311 

-22.973 

-20,094 

-12.669 

-10,072 

-7,544 

-3*307 

-2.604 

-1,605 

1,183 

1.359 

1*411 

-185,667 

-179.167 

-172.667 

-150,917 

“146,167 

-140.542 

“116.875 

-110.792 

-104.792 

-88,042 

-83,458 

-80,042 

-60.875 

-57.958 

-53.292 

-39,70.0 

-35,422 

-30,723 

-19,567 

-16.408 

-14.619 

-6.707 

-5,655 

-4,016 

-0,371 

0.132 

0 . 934 

1,387 

1 , 053 
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req; 
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1 

< 

9) 

1 

3 

4 

11 

13 

2 

< 

4) 

2 

6 

10 

12 

3 

(15) 

5 

17 

18 

19 

20 

43 

44 

53 

62 

65 

4 

< 

7) 

7 

14 

24 

57 

58 

5 

(10) 

8 

9 

27 

46 

47 

6 

< 

6) 

25 

26 

28 

29 

30 

7 

< 

9) 

31 

32 

33 

34 

35 

8 

< 

5) 

37 

38 

39 

40 

45 

req; 
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♦ 

/2 > 6 > 10 > 1 2 >  5  ?-l  7 t 18 > 1 9 > 20 > 2 If 22  >23 


15 

16 

56 

64 
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22 

23 

41 

42 

60 

48 

61 

49 

50 

51 

52 

59 

36 

54 

55 

63 

41 > 42 > 43  > 44 >53  >  62  >  65  >  7  >1 4  >  24 1 57 » 


58  >  60  >61  >  8  >  9  >  27  >  46  >  47  >  48  >  49  >  50  >  5 1>  52  >25  >26  >  23  >29  >.30.  >  59  >  3 1  >  32  >  33  > 
♦ 
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7 

8 
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10 

12 

14 
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18 
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20 

21 

22 

23. 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 
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42 

43 

44 

45 

46 

47 

43 

49 

50 
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52 

53 

54 

55 

57 

58 

59 

60 

61 

62 

63 

65 

NODES  HAVE  BEEN  RENAMED  AS  FOLLOWS; 
OLD  NQ*  NEW' NO* 
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3 

4 
11 
13 

15 
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56 
64 


3. 
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3 

A 

•S 
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7 

3 

9 
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5?  17/ 
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?  •  20  7 

21?  22? 
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* 
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..  O  ..  \>7 
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?  48 
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2 

/ 

”7 

/ 

8 

9 

10 

12 

14 

17 

13 

1  'V 

20 

21 

23 

24 

25 

26 

27 

23 

29 

30 

31. 

32 

33 

34 

35 

36 

37 

m 

'39 

40 

£  1 

V  .1. 

42 

43 

4  4 

45 

46 

47 

<u-> 

,-jo 

50 

k;** 

W  M 

K  *} 

\h  Am 

53 

54 

55 

57 

58 

39 

60 

61 

A'.) 

W<k< 

61 

65 

ronniTO  i 

!!A,,E 

DEEM 

remaned 

AS  FTl!.. 

LOWS  ? 

OLD  NO 

•  NIL 

U  NO, 

4 

1.1 


! 


1,6 

i~  »• 
. ; ... 

i  4 


6 

’7 


Q 

o 


o 

■4;.:rr.  f 
•v'jtjM 

( !'•  E  o  L  U  3  T  £  R  I  g  c  n  w  p  i  c  ~  r 
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DECT  PART  IT  l  ON  MEASURE  ?  O :  ^r, 
DU  VO':  WAWT  TO  PRINT  THE  rppr-p 
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o’crj’i  •» 
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*# 

?  :>  - 

!? 

1  !.  ?  1 

3?  15/1 

6/54 

?6 

1  C“ 

17? 18? 19? 

20 

r  2 1  ? 

22 ? 23? 

41  7 

42 

?  43  ? 

44  ? 

7  6 

5  ?  7  y 

14-  2-1/ 

57  7  5B>/ 

60?  4 

■It  0/ 

9?  27? 

46 

?  4  7  ? 

48  ?  49 v 

50  r 

31 

?  52  7 

<21 

2 

3  •  2? 

?  30  :■  59 

?  3 1  ? 

32 

•/  O.!  7 

34  ■/  35  ?  36  ? 

54 

7  \mn  \J  V 

63? 37 ? 30 t 

39 

?  40  ? 

45/ 

HE 

FOLLOW 

IMG  NO 

DES 

HA 

VE  D 

SEN 

REMOVED 

* 

:l 

w* 

/• 

c; 

7 

8 

9 

11 

13 

14 

IS 

16 

i  y 

10 

19 

20 

21 

90 

Ah  Ah 

23 

24 

'ik; 

mt  w 

24 

:>/ 

9  Q 

Aw  ',7 

r>Q 

30 

31 

32 

33 

34 

35 

34 

37 

30 

39 

40 

41 

42 

43 

44 

45 

46 

47 

40 

49 

50 

51 

52 

53 

54 

55 

65 

56 

V  ■? 

50 

59 

60 

41 

62 

63 

(A 

ODE 

\2 

HAVE 

BEEN 

RENAME 

Ti  A  <5 

FOLLOWS  T 

old  no.  NKir  no 


,*j  MN 

■ F  H:  !:  C U  8  T  £  R  I  N  0  C  0  M  P )...  E  T  E ) 

''RECLUSTERIMO  PERFORM  EE'  AND  DISTANCE  MATRIX  COMPUTED  vJI"H  P 
(MUSTERS  NOT  TAKEN  AS  SINGLE  NODES : 
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:~MiE 

BEST  PARTI"' I  ON  MEASURE’  0,33:3 
HO  YD'i  WAN-  TO  PRINT  !'!E  TREE? 

Mil 


Vrm.  i  ;j  _ 

y  it <•; r £ iv  ( n q >  n *?  j r r t q 

'»  {  4 v  ’!  3 


2  "'REM1'!-1  ?  0 .  I  "  "J ; 

j  0 ! 1. 1  P  *  o  f'  c 
ME. -.SURF?  ‘T' 


C 


TTTT. 


Mn 

:  3  r  A 

.-.!  Is- 13 

'■  15 

- 16.-56 

?  6.4' s-  2 

?'6  ?  1 

0  ?  1 2  ?  5  r 

17?  13 

/.!.?? 

20?  2- 

53/42  • 

15;? 

Sr?. -27 

;•  ;F\4 !  4 

7.-48 

:•  49/50? 

51/52 

? 

h  ? 

20 ..  2?  ? 

30 .. 

59/31- 

32/33 

'3A? 

35? 36. -54 -55? 

63  ?  3 

7-38 

IE  F 

C- ;!i.!  I 

NB 

NODES 

HAVE  . 

-lEEM 

REMOVE 

fi ; 

•t 

X 

3 

4 

5 

A 

8 

o 

10 

11 

<| 

•!_  3 

15 

16 

17 

13 

1? 

20 

2 1 

77 

.W.  m 

9  T 

*M  V 

25 

26 

27 

28 

2? 

30 

3 1 

32 

33 

34 

35 

*♦  j 

3? 

38 

39 

40 

■4.1 

42 

43 

44 

45 

4  6 

47 

48 

•49 

SO 

51 

52 

IT* 

%Jv3 

5« 

rr.t; 

W 

56 

59 

42 

63 

64 

65 

HOPES  HAVE  B EEH  RENAMED  AS  FOLLOWS  * 
CLD  K*  NEW  HO, 


FEEs  f:»  x 

nyf/M'i 

<  p PEC LUSTER  I  MB  COMPLETE ) 


PPECL.USTEPINB  PERFORMED  AND  DISTANCE  MATRIX  COMPUTED  WITH 
CLUSTERS  WOT  TAKEN  AS  SINGLE  NODES* 


REG  * 

HCNS 

9cS r  PARTITT'V!  MEASURE *  0,33: 

Jjn  YOU  W*NT  f‘0  PRINT  TREE? 

Mi! 


CLUSTER  (NO)  OBJECTS 
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REQi 
DENQ 
♦  - 

/U3t4:t  ll*13n5rl6i5$r64>2>6r  lQ»12j5rL7.,i8f  L? >20  721*22*23, 41>42r 
♦ 

43?44»53f62r65*7»i4>24>57»5ay6.0>61y.25>26f28>29>30.>5??31y32»33*34» 

•» 

♦ 

35>36f54r55>63>37i»38>39r40»45/ 

THE  FOLLOWING.  NODES  HAVE  BEEN  REMOVED: 


1 

r> 

Am 

3 

4 

5 

6 

7 

10 

11 

12 

13 

14 

15 

■16 

17 

IS 

19 

20 

21 

*?r> 

Am  Am 

23 

'  24 

25 

26- 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

NODES  HAVE  BEEN  RENAMED  AS  FOLLOWS: 
OLD  NO  *  NEW  NO  * 


8  1 

9  2 

27  3 

46  4 

47  5 

48  6 

49'  7 

50  3 

51  9 


52 

bV-'n 

'  "‘RE 


10 


U  9  T  ’£  K:  I  >'  >■}  C  Q  M  p  l. .  E 1  2 


>3  O  i;  pj  j  ‘  C;  V 

•: rKi^j 


EP  \  'G  !“’£R»* ' 
MOT  TJ»KE'i 


AS 


■D  AND 
SIMOLr 


DISTANCE 
NODES > 


MATRIX  COMPUTED  WITH  P 


! 


»♦ 


NR'!** 

(>  r  r.  p,A  ■[•  r 
D "  "0!.i  Ui,M'r 
NC 


v  s  ».\!  ME  AS  URE :  0 , 524 

T  \  1. NT  THE  TREE? 


R1  !i:TER  ■  MO  1  CflJ£CT'S 

“X  \  J  « 

* )  .* 


-?  O 


I  v 


I  o 
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q  ■> 
Vf 


* 

<  7  i  4 

:*  !.  1  :■  1 

,  i  l 

.•  1 

6 y  5 

A  A  A  2 

.*  6  :■  10  7 

•i  ir 

r  /  n  ”1  •! 

17  7  13 

7 19 7 20 

7  2 

i<3 

$ 

,  \  -  • 

•  ••  *.y  *  ^ 

,.v 

?65y 

77 

*  r 

14? 

24.«37i- 

58y  60? 

61  7  07 

O  ,  27  y 

46  .’47.« 

48. 

rX 

.>  12 1 

••V  l*M 

? 

3  6 

•>  54 

:■  55  7  63 

i*  3  7  ?  3  8 

39  ?'4 

0  7  45/ 

' V 

J 

ur  i- 

rji  ;  rjM 

T  NS  : 

.‘.jO 

rrf  s 
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DEEM  R 

EMC1  ME 

D  ? 

t 

J? 

5 

6 

7' 

3 

9 

10 

5.'! 

1Z 

1  4 

i  s 

,  16 

17 

13 

19 

6  '\ 
7~  V 

2 1 

22 

23 

.24 

27 

31 

32 

■•V 

iff  w 

34 

35 

36 

“V  ~l 

.5/ 

3S 

3.9 

40 

41; 

4,2 

43 

/&  ^ 

45 

46 

47 

.iP 

49 

50 

51 

52 

53 

54 

55 

54 

•57 

'■■•:  2 

,»  rt 

av 

61. 

62 

63 

6  4 

65 

NC,r:s  S' 

H,'  ME 

Kcjrsr 

M 

RENAMED  A 

S  PQl.L 

OHS  * 

r\s  •'!!) !  MEN 


ft 

■'  R E  t L U S 7 E  R I  MG  C 0  M p l, £ TE? 
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CLUSTERS  MCT  FAKci’!  4  b  SINGLE  NODES . 

.OCT!  ' 
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**•  4  V  |  9 


-*  *  I  •  I  !,*  -  -JIVI  f 
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. .  'T  *  ?  .■ 

*  .4  |  «v 
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r  56 

:•  6  .•  2 

-6 

1 1 0  ? 

12  ?  5  :• 

17?  IS 

?  19?  20 

r  2 1 

„*  S ' 

3  -  :>?.  .• 

65?  7  -1 

A  ,  2 

4/57.- 

30 

■60  ? 

*  *  n 
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9.-27  ■ 
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BE  3 
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1 

•T 

"» 

.-j 

C.J 

l 

7 

s 

;•> 

io 

’! 

•i  /) 

13 
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} 

1  A 

3.7 

18 

1.9 

20 

J>  J 

90 

•Ym  ... 

a 

24 

2  '5 

/ 

t.f 

77 

28 

29 

30 

.P 

30 

TO 
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40 

41 

42 

43 

44 

43 

46 
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50 
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so 

(M 

53 

56 

57 

58 
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42 

44 

65 
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rlQ  r'.J  *  i\  *r  *  -?c 

/*  {y  ty* 

or**  "  t^p*} 


“>  V*  »*•.  |~ 


m 


A 


*%r*g$* &  . 


-  300  - 
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APPENDIX  J 


Main  Subproblems  Resulting  From  The 
Second-  Iteration  of  the  Decomposition  Analysis 


Note;  (11)  The  number  in  the  parenthesis  indicates 

the  number  of  interdependencies  identified 
for  the  requirement. 


Main  Subproblem,  1:  Supervisor  Process: 

7  (10) :  The  operating  system  must  provide,  for  a  multi¬ 

programming  environment.-- 

9  (  8) :  All  resource  requests  must  pass  through  the 
supervisor. 

10  (  8):  System  resources  must  be  allocated  to  a  job  prior 
to  it  being  runnable. 

17-  {  5) :  System  process  routines  are  re-entrant  and  shared. 
19  (  9) :  Supervisor  process  must  schedule  jobs  and  prepare 
them  for  executions 

21  (  5) :  Jobs  are  initiated  strictly  on  a  first-come,  first 

served  basis. 

22  (  3) :  Supervisor  process  must  be  modularized  so  that 

improvements  are  easy. 

62  (  2) :  Supervisor  process  must  load  -the  user-supplied 
object  deck  into  memory. 

70  (  9) :  There  is  one  supervisor  process  per  job  stream. 

Main  Subproblem  2:  Extended  Machine  Instruction  Mechanism: 

8  (  5) :  Operating  system  must  run  on  a  machine  that  has 

two  states. 

12  (  8) :  User  communication  with  operating  system  is  via 
special  call. 

16  (  5):  Certain  system  routines  are  user  callable. 

18  (  4) :  Extended  machine  instructions  are  executed  in  the 
supervisor  state. 

Main  Subproblem  3 :  Process  Control  Functions : 
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SUBPROBLEM  MS  >A  -  Process-Scheduling: 

11  (  6) :  A. process  must  be  ready  to  run  prior  to  being 
allocated  a  processor. 

24  (  7) :  Ready  processes  are  scheduled  in  round-robin 

fashion  by  process  scheduler. 

26  (  6) :  A  process  shall  be  blocked  when  awaiting  synchron¬ 

ization. 

59  (  6) :  If  no  messages  are  available  to  a  process  explicitly 
then  it  goes  blocked. 

71  (  3):  I/O  interrupt  handler  must  provide  for  a  synchronous 
scheduling  of  a  process  requiring  fast  processing. 
SUBPROBLEM  MS  3-B  -  System  Initiated  Interrupts: 

23  (  3):  Process  scheduler  must  time-slice  CPU  usage. 

25  (  9) :  A  process  shall  be  blocked  when  its  time  quantum 

is  exceeded. 

47  (  7) :  Interrupt  handler  must  be  provided  for  I/O 
interrupts . 

49  (  6) :  Interrupt  handler 'must  be  provided  for  supervisor 

call  interrupts. 

50  (  5) :  Interrupt  handler  must  be  provided  for  external 

interrupts. 

SUBPROBLEM  MS  3-C  -  User  Process  Initiated  Interrupts: 

27  (  4) :  A  process  shall  be  blocked  when  it  specifically 

relinquishes  control. 

28  (10) :  Supervisor  routine  must  reclaim  all  system  resources 


when  a  job  is  completed. 


29  {  5) :  Supervisor  must  reclaim  resources  when  an  error 

condition  is  raised; 

48  (  8)  ;  Interrupt  handler  must  be  provid's  i  for  program 
interrupts . 

68  (  7) :  User  process  must  signal  completion  to  the  opera¬ 
ting;  system. 

Main  Subproblem,  4 :  Process  Creation  Functions: 

13  (  7) :  Operating  system,  must,  protect  user  jobs  from  each 

other. 

20  (  3):  Initially  one  process  is  created  for  each  user's 
job. 

30  (  5):,  Reference  to  a  process  is  by  symbolic  name. 

63  (  5):  All  processes  may  dynamically  create  additional 

processes. 

64  (  7) :  Dynamically  created  processes  run  on  the  same 

memory  area  as  parent  job. 

66  (  6) :  User  processes  can  destroy  other  user  processes 

only  within  the  same  group. 

67  (  5) :  User  processes  run  in  the  problem  state. 

Main  Subproblem  5:  Interprocess  Communication: 

MS  5-A  -  Operating  System  Information  Tables: 

14  (10) :  Operating  system  must  utilize  information  tables 

to  monitor  and  control, 

15  (  4) :  System  tables  can  be  dynamically  allocated  and 

released. 

33  (  9) :  Operating  system  may  dynamically  allocate  memory 


to  itself  for  workspace. 

MS  5-B  -  Message  Facility 

52  (10) :  Message  -facility  must  be  provided  to  all  processes i 

53  (  5) :  Processes  receiving  messages  must  be  able  to 

determine  the  originator. 

54  (  6) :  Receiving  process  may  read  the  name  and  text  from 

originator . 

55  (  2) :  Messages  are  of  an  arbitrary  yet  specified  length. 

56  (  7)  :  Any  number  of  messages  may  be  queued. 

57  (  4):  All  messages  are  released  when  a  process  terminates. 

58  (  4) :  Messages  are  not  receipted  for. 

Main  Subproblem  6:  Memory  Allocation  Functions: 

31  (  8) :  The  operating  system  must  allocate  memory  for  a  job. 

32  (  8) :  Memory  is  allocated  to  a  job  in  contiguous  2K 

blocks. 

34  (  4) :  Memory  is  allocated  using  a  best-fit  algorithm. 

35  (  7) :  Memory  must  be  protected  to  prevent  simultaneous 

allocation. 

36  (  7) :  Free  storage  areas  are  collapsed  into  blocks  when 

a  job  is  freed. 

65  (  5) :  User  processes  cannot  dynamically  allocate  memory. 

Main  Subproblem  7:  Device  Management  Functions: 

37  (13) :  Operating  system  must  supply  a  device  management 

system. 

38  (  5) :  Device  handler  routines  must  support  multiple  job 


streams . 


.39  (  8) :  A  device:  is  dedicated  to  a  job. 


40  (10.)  : 


41  (.6): 

42  (  8)-: 

60  (12)  : 


•  61  (  6)  : 


69  (7): 


The  device  handler'  routine  supports  one  card 
reader  per  input  stream. 

The  device  handler  routine  must  support  one  line 
printer. 

The  user  can  provide  his  own  routines  for  non- 
standard  devices. 

User  programs  use  JCL  to  specify  resource 
requirements . 

Operating  system  must  accept  input  data  from  user’ 
job  stream. 

User's  job  can  reference  at  most  1  input,  1  output 
and  1  non-standard  device. 


Main  Subproblem  8:  Process  Synchronization  Functions: 

43  (10) :  A  process  synchronization  mechanism  must  be 

provided  as  a  lock  database. 

44  (  7) :  A  process  synchronization  mechanism  must  be  pro¬ 

vided  for  synchronous  process. 

45  (  5) :  A  process  synchronization  mechanism  must  be  pro¬ 

vided  for  sender  and  receiver  of  messages. 

46  (10) :  A  process  synchronization  mechanism  must  be 

provided  to  lock  a  device. 

51  (  6) :  P-V  operations  are  available  or.ly  to  system 


processes. 


LINKAGE  -  INTERFACE  ASSESSMENT 


.Subproblem 

Process  Scheduling 
System  Initiated. 

Interrupt  Handler 
User  Initiated  Interrupt 
Handler 

Process  Sychronization 
Mechanism 

Memory  Allocation 
Operating  System 
Information  Tables 

Process  Creation 
Message  Facility 

Device  Management 
Functions 

Supervisor  Process 


Cluster 

Number 

3 

4 

5 

11 

9 

7 

6 

8 

10 

1 


Module 


Process  Management 
(lower)  Module 


Memory  Management 
Module 

Process  Management 
(upper)  Module 

Device  Management 
Module 

Supervisor  Process 
Module 


Extended  Machine 
Instruction  Mechanism 


2 


Supervisor  Call 
Handler 


NUMBER  OF  LINKAGES  BETWEEN  SUBPROBLEMS 


